1. 26 10月, 2022 1 次提交
  2. 14 10月, 2022 1 次提交
    • J
      i40e: Fix DMA mappings leak · aae425ef
      Jan Sokolowski 提交于
      During reallocation of RX buffers, new DMA mappings are created for
      those buffers.
      
      steps for reproduction:
      while :
      do
      for ((i=0; i<=8160; i=i+32))
      do
      ethtool -G enp130s0f0 rx $i tx $i
      sleep 0.5
      ethtool -g enp130s0f0
      done
      done
      
      This resulted in crash:
      i40e 0000:01:00.1: Unable to allocate memory for the Rx descriptor ring, size=65536
      Driver BUG
      WARNING: CPU: 0 PID: 4300 at net/core/xdp.c:141 xdp_rxq_info_unreg+0x43/0x50
      Call Trace:
      i40e_free_rx_resources+0x70/0x80 [i40e]
      i40e_set_ringparam+0x27c/0x800 [i40e]
      ethnl_set_rings+0x1b2/0x290
      genl_family_rcv_msg_doit.isra.15+0x10f/0x150
      genl_family_rcv_msg+0xb3/0x160
      ? rings_fill_reply+0x1a0/0x1a0
      genl_rcv_msg+0x47/0x90
      ? genl_family_rcv_msg+0x160/0x160
      netlink_rcv_skb+0x4c/0x120
      genl_rcv+0x24/0x40
      netlink_unicast+0x196/0x230
      netlink_sendmsg+0x204/0x3d0
      sock_sendmsg+0x4c/0x50
      __sys_sendto+0xee/0x160
      ? handle_mm_fault+0xbe/0x1e0
      ? syscall_trace_enter+0x1d3/0x2c0
      __x64_sys_sendto+0x24/0x30
      do_syscall_64+0x5b/0x1a0
      entry_SYSCALL_64_after_hwframe+0x65/0xca
      RIP: 0033:0x7f5eac8b035b
      Missing register, driver bug
      WARNING: CPU: 0 PID: 4300 at net/core/xdp.c:119 xdp_rxq_info_unreg_mem_model+0x69/0x140
      Call Trace:
      xdp_rxq_info_unreg+0x1e/0x50
      i40e_free_rx_resources+0x70/0x80 [i40e]
      i40e_set_ringparam+0x27c/0x800 [i40e]
      ethnl_set_rings+0x1b2/0x290
      genl_family_rcv_msg_doit.isra.15+0x10f/0x150
      genl_family_rcv_msg+0xb3/0x160
      ? rings_fill_reply+0x1a0/0x1a0
      genl_rcv_msg+0x47/0x90
      ? genl_family_rcv_msg+0x160/0x160
      netlink_rcv_skb+0x4c/0x120
      genl_rcv+0x24/0x40
      netlink_unicast+0x196/0x230
      netlink_sendmsg+0x204/0x3d0
      sock_sendmsg+0x4c/0x50
      __sys_sendto+0xee/0x160
      ? handle_mm_fault+0xbe/0x1e0
      ? syscall_trace_enter+0x1d3/0x2c0
      __x64_sys_sendto+0x24/0x30
      do_syscall_64+0x5b/0x1a0
      entry_SYSCALL_64_after_hwframe+0x65/0xca
      RIP: 0033:0x7f5eac8b035b
      
      This was caused because of new buffers with different RX ring count should
      substitute older ones, but those buffers were freed in
      i40e_configure_rx_ring and reallocated again with i40e_alloc_rx_bi,
      thus kfree on rx_bi caused leak of already mapped DMA.
      
      Fix this by reallocating ZC with rx_bi_zc struct when BPF program loads. Additionally
      reallocate back to rx_bi when BPF program unloads.
      
      If BPF program is loaded/unloaded and XSK pools are created, reallocate
      RX queues accordingly in XSP_SETUP_XSK_POOL handler.
      
      Fixes: be1222b5 ("i40e: Separate kernel allocated rx_bi rings from AF_XDP rings")
      Signed-off-by: NJan Sokolowski <jan.sokolowski@intel.com>
      Signed-off-by: NMateusz Palczewski <mateusz.palczewski@intel.com>
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: Chandan <chandanx.rout@intel.com> (A Contingent Worker at Intel)
      Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aae425ef
  3. 01 9月, 2022 1 次提交
  4. 25 8月, 2022 1 次提交
  5. 23 7月, 2022 1 次提交
  6. 01 7月, 2022 1 次提交
  7. 22 6月, 2022 1 次提交
  8. 09 6月, 2022 1 次提交
    • A
      i40e: Fix call trace in setup_tx_descriptors · fd5855e6
      Aleksandr Loktionov 提交于
      After PF reset and ethtool -t there was call trace in dmesg
      sometimes leading to panic. When there was some time, around 5
      seconds, between reset and test there were no errors.
      
      Problem was that pf reset calls i40e_vsi_close in prep_for_reset
      and ethtool -t calls i40e_vsi_close in diag_test. If there was not
      enough time between those commands the second i40e_vsi_close starts
      before previous i40e_vsi_close was done which leads to crash.
      
      Add check to diag_test if pf is in reset and don't start offline
      tests if it is true.
      Add netif_info("testing failed") into unhappy path of i40e_diag_test()
      
      Fixes: e17bc411 ("i40e: Disable offline diagnostics if VFs are enabled")
      Fixes: 510efb26 ("i40e: Fix ethtool offline diagnostic with netqueues")
      Signed-off-by: NMichal Jaron <michalx.jaron@intel.com>
      Signed-off-by: NAleksandr Loktionov <aleksandr.loktionov@intel.com>
      Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      fd5855e6
  9. 08 6月, 2022 1 次提交
    • M
      i40e: Add VF VLAN pruning · c87c938f
      Mateusz Palczewski 提交于
      VFs by default are able to see all tagged traffic regardless of trust
      and VLAN filters configured.
      
      Add new private flag vf-vlan-pruning that allows changing of default
      VF behavior for tagged traffic. When the flag is turned on
      untrusted VF will only be able to receive untagged traffic
      or traffic with VLAN tags it has created interfaces for
      
      The flag is off by default and can only be changed if
      there are no VFs spawned on the PF. This flag will only be effective
      when no PVID is set on VF and VF is not trusted.
      Add new function that computes the correct VLAN ID for VF VLAN filters
      based on trust, PVID, vf-vlan-prune-disable flag and current VLAN ID.
      
      Testing Hints:
      
      Test 1: vf-vlan-pruning == off
      ==============================
      1. Set the private flag
      > ethtool --set-priv-flag eth0 vf-vlan-pruning off (default setting)
      2. Use scapy to send any VLAN tagged traffic and make sure the VF
      receives all VLAN tagged traffic that matches its destination MAC
      filters (unicast, multicast, and broadcast).
      
      Test 2: vf-vlan-pruning == on
      ==============================
      1. Set the private flag
      > ethtool --set-priv-flag eth0 vf-vlan-pruning on
      2. Use scapy to send any VLAN tagged traffic and make sure the VF does
      not receive any VLAN tagged traffic that matches its destination MAC
      filters (unicast, multicast, and broadcast).
      3. Add a VLAN filter on the VF netdev
      > ip link add link eth0v0 name vlan10 type vlan id 10
      4. Bring the VLAN netdev up
      > ip link set vlan10 up
      4. Use scapy to send traffic with VLAN 10, VLAN 11 (anything not VLAN
      10), and untagged traffic. Make sure the VF only receives VLAN 10
      and untagged traffic when the link partner is sending.
      
      Test 3: vf-vlan-pruning == off && VF is in a port VLAN
      ==============================
      1. Set the private flag
      > ethtool --set-priv-flag eth0 vf-vlan-pruning off (default setting)
      2. Create a VF
      > echo 1 > sriov_numvfs
      3. Put the VF in a port VLAN
      > ip link set eth0 vf 0 vlan 10
      4. Use scapy to send traffic with VLAN 10 and VLAN 11 (anything not VLAN
      10) and make sure the VF only receives untagged traffic when the link
      partner is sending VLAN 10 tagged traffic as the VLAN tag is expected
      to be stripped by HW for port VLANs and not visible to the VF.
      
      Test 4: Change vf-vlan-pruning while VFs are created
      ==============================
      echo 0 > sriov_numvfs
      ethtool --set-priv-flag eth0 vf-vlan-pruning off
      echo 1 > sriov_numvfs
      ethtool --set-priv-flag eth0 vf-vlan-pruning on (expect failure)
      Signed-off-by: NSylwester Dziedziuch <sylwesterx.dziedziuch@intel.com>
      Signed-off-by: NPrzemyslaw Patynowski <przemyslawx.patynowski@intel.com>
      Signed-off-by: NMateusz Palczewski <mateusz.palczewski@intel.com>
      Tested-by: NKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      c87c938f
  10. 13 4月, 2022 2 次提交
  11. 09 2月, 2022 4 次提交
  12. 22 11月, 2021 1 次提交
  13. 24 8月, 2021 1 次提交
  14. 23 7月, 2021 2 次提交
  15. 25 6月, 2021 1 次提交
  16. 08 5月, 2021 3 次提交
  17. 09 4月, 2021 1 次提交
  18. 02 4月, 2021 1 次提交
  19. 26 3月, 2021 1 次提交
  20. 24 3月, 2021 1 次提交
  21. 18 3月, 2021 1 次提交
  22. 19 2月, 2021 1 次提交
  23. 16 2月, 2021 1 次提交
  24. 11 2月, 2021 4 次提交
    • P
      i40e: VLAN field for flow director · a9219b33
      Przemyslaw Patynowski 提交于
      Allow user to specify VLAN field and add it to flow director. Show VLAN
      field in "ethtool -n ethx" command.
      Handle VLAN type and tag field provided by ethtool command. Refactored
      filter addition, by replacing static arrays with runtime dummy packet
      creation, which allows specifying VLAN field.
      Previously, VLAN field was omitted.
      Signed-off-by: NPrzemyslaw Patynowski <przemyslawx.patynowski@intel.com>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      a9219b33
    • P
      i40e: Add flow director support for IPv6 · efca91e8
      Przemyslaw Patynowski 提交于
      Flow director for IPv6 is not supported.
      1) Implementation of support for IPv6 flow director.
      2) Added handlers for addition of TCP6, UDP6, SCTP6, IPv6.
      3) Refactored legacy code to make it more generic.
      4) Added packet templates for TCP6, UDP6, SCTP6, IPv6.
      5) Added handling of IPv6 source and destination address for flow director.
      6) Improved argument passing for source and destination portin TCP6, UDP6
         and SCTP6.
      7) Added handling of ethtool -n for IPv6, TCP6,UDP6, SCTP6.
      8) Used correct bit flag regarding FLEXOFF field of flow director data
         descriptor.
      
      Without this patch, there would be no support for flow director on IPv6,
      TCP6, UDP6, SCTP6.
      Tested based on x710 datasheet by using:
      ethtool -N enp133s0f0 flow-type tcp4 src-port 13 dst-port 37 user-def 0x44142 action 1
      ethtool -N enp133s0f0 flow-type tcp6 src-port 13 dst-port 40 user-def 0x44142 action 2
      ethtool -N enp133s0f0 flow-type udp4 src-port 20 dst-port 40 user-def 0x44142 action 3
      ethtool -N enp133s0f0 flow-type udp6 src-port 25 dst-port 40 user-def 0x44142 action 4
      ethtool -N enp133s0f0 flow-type sctp4 src-port 55 dst-port 65 user-def 0x44142 action 5
      ethtool -N enp133s0f0 flow-type sctp6 src-port 60 dst-port 40 user-def 0x44142 action 6
      ethtool -N enp133s0f0 flow-type ip4 src-ip 1.1.1.1 dst-ip 1.1.1.4 user-def 0x44142 action 7
      ethtool -N enp133s0f0 flow-type ip6 src-ip fe80::3efd:feff:fe6f:bbbb dst-ip fe80::3efd:feff:fe6f:aaaa user-def 0x44142 action 8
      Then send traffic from client which matches the criteria provided to ethtool.
      Observe that packets are redirected to user set queues with ethtool -S <interface>
      Signed-off-by: NPrzemyslaw Patynowski <przemyslawx.patynowski@intel.com>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      efca91e8
    • A
      i40e: Add EEE status getting & setting implementation · 95f352dc
      Aleksandr Loktionov 提交于
      Implement Energy Efficient Ethernet (EEE) status getting & setting.
      The i40e_get_eee() requesting PHY EEE capabilities from firmware.
      The i40e_set_eee() function requests PHY EEE capabilities
      from firmware and sets PHY EEE advertising to full abilities or 0
      depending whether EEE is to be enabled or disabled.
      Signed-off-by: NAleksandr Loktionov <aleksandr.loktionov@intel.com>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      95f352dc
    • A
      i40e: Add init and default config of software based DCB · 4b208eaa
      Arkadiusz Kubalewski 提交于
      Add extra handling on changing the "disable-fw-lldp" private
      flag to properly initialize software based DCB feature.
      
      Add default configuration of DCB functionality when Firmware
      LLDP agent is turned off, in case of driver probe and device
      reset on reconfiguration.
      
      Update copyright dates as appropriate.
      
      Software based DCB is a brand-new feature in i40e driver.
      Before, DCB was implemented by Firmware LLDP agent only. The agent was
      responsible for handling incoming DCB-related LLDP frames and
      applying received DCB configuration to hardware.
      
      Default configuration and new initialization flow for software based
      DCB is required. If LLDP agent is turned off in BIOS, or after
      setting private flag ("disable-fw-lldp on"). The driver initializes
      DCB functionality with default values, one traffic class with 100%
      bandwidth allocated.
      Signed-off-by: NAleksandr Loktionov <aleksandr.loktionov@intel.com>
      Signed-off-by: NArkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      4b208eaa
  25. 14 10月, 2020 1 次提交
  26. 01 9月, 2020 1 次提交
  27. 02 7月, 2020 2 次提交
    • A
      i40e: Add support for a new feature Total Port Shutdown · d5ec9e2c
      Arkadiusz Kubalewski 提交于
      After OS requests to down a link on a physical network port, the
      traffic is no longer being processed but the physical link with
      a link partner is still established.
      
      Currently there is a feature (Link down on close) which allows
      to physically bring the link down (after OS request).
      
      With this patch new feature with similar capability is introduced:
      TOTAL_PORT_SHUTDOWN
      Allows to physically disable the link on the NIC's port.
      If enabled, (after link down request from the OS)
      no link, traffic or led activity is possible on that port.
      
      If I40E_FLAG_TOTAL_PORT_SHUTDOWN is enabled, the
      I40E_FLAG_LINK_DOWN_ON_CLOSE_ENABLED must be explicitly forced to
      true and cannot be disabled at that time.
      The functionalities are exclusive in terms of configuration, but
      they also have similar behavior (allowing to disable physical link
      of the port), with following differences:
      - LINK_DOWN_ON_CLOSE_ENABLED is configurable at host OS run-time
        and is supported by whole family of 7xx Intel Ethernet Controllers
      - TOTAL_PORT_SHUTDOWN may be enabled only before OS loads (in BIOS)
        only if motherboard's BIOS and NIC's FW has support of it
      - when LINK_DOWN_ON_CLOSE_ENABLED is used, the link is being brought
        down by sending phy_type=0 to NIC's FW
      - when TOTAL_PORT_SHUTDOWN is used, phy_type is not altered, instead
        the link is being brought down by clearing bit
        (I40E_AQ_PHY_ENABLE_LINK) in abilities field of
        i40e_aq_set_phy_config structure
      
      Introduced changes:
      - new private flag I40E_FLAG_TOTAL_PORT_SHUTDOWN for handling the
        feature
      - probe of NVM if the feature was enabled at driver's port
        initialization
      - special handling on link-down procedure to let FW physically
        shutdown the port if the feature was enabled
      Signed-off-by: NArkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
      Signed-off-by: NAleksandr Loktionov <aleksandr.loktionov@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      d5ec9e2c
    • J
      ethernet/intel: Convert fallthrough code comments · 5463fce6
      Jeff Kirsher 提交于
      Convert all the remaining 'fall through" code comments to the newer
      'fallthrough;' keyword.
      Suggested-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      5463fce6
  28. 26 6月, 2020 1 次提交
    • J
      net/intel: remove driver versions from Intel drivers · 34a2a3b8
      Jeff Kirsher 提交于
      As with other networking drivers, remove the unnecessary driver version
      from the Intel drivers. The ethtool driver information and module version
      will then report the kernel version instead.
      
      For ixgbe, i40e and ice drivers, the driver passes the driver version to
      the firmware to confirm that we are up and running.  So we now pass the
      value of UTS_RELEASE to the firmware.  This adminq call is required per
      the HAS document.  The Device then sends an indication to the BMC that the
      PF driver is present. This is done using Host NC Driver Status Indication
      in NC-SI Get Link command or via the Host Network Controller Driver Status
      Change AEN.
      
      What the BMC may do with this information is implementation-dependent, but
      this is a standard NC-SI 1.1 command we honor per the HAS.
      
      CC: Bruce Allan <bruce.w.allan@intel.com>
      CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
      CC: Alek Loktionov <aleksandr.loktionov@intel.com>
      CC: Kevin Liedtke <kevin.d.liedtke@intel.com>
      CC: Aaron Rowden <aaron.f.rowden@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Co-developed-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      34a2a3b8
  29. 19 6月, 2020 1 次提交