1. 16 4月, 2022 2 次提交
  2. 19 2月, 2022 1 次提交
  3. 01 2月, 2022 2 次提交
  4. 28 1月, 2022 1 次提交
  5. 14 12月, 2021 1 次提交
  6. 30 10月, 2021 1 次提交
  7. 28 9月, 2021 1 次提交
  8. 25 6月, 2021 1 次提交
    • T
      intel: Remove rcu_read_lock() around XDP program invocation · 49589b23
      Toke Høiland-Jørgensen 提交于
      The Intel drivers all have rcu_read_lock()/rcu_read_unlock() pairs around
      XDP program invocations. However, the actual lifetime of the objects
      referred by the XDP program invocation is longer, all the way through to
      the call to xdp_do_flush(), making the scope of the rcu_read_lock() too
      small. This turns out to be harmless because it all happens in a single
      NAPI poll cycle (and thus under local_bh_disable()), but it makes the
      rcu_read_lock() misleading.
      
      Rather than extend the scope of the rcu_read_lock(), just get rid of it
      entirely. With the addition of RCU annotations to the XDP_REDIRECT map
      types that take bh execution into account, lockdep even understands this to
      be safe, so there's really no reason to keep it around.
      Signed-off-by: NToke Høiland-Jørgensen <toke@redhat.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Tested-by: Jesper Dangaard Brouer <brouer@redhat.com> # i40e
      Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
      Cc: Tony Nguyen <anthony.l.nguyen@intel.com>
      Cc: intel-wired-lan@lists.osuosl.org
      Link: https://lore.kernel.org/bpf/20210624160609.292325-12-toke@redhat.com
      49589b23
  9. 03 6月, 2021 1 次提交
  10. 02 4月, 2021 1 次提交
    • M
      i40e: fix receiving of single packets in xsk zero-copy mode · 528060ef
      Magnus Karlsson 提交于
      Fix so that single packets are received immediately instead of in
      batches of 8. If you sent 1 pps to a system, you received 8 packets
      every 8 seconds instead of 1 packet every second. The problem behind
      this was that the work_done reporting from the Tx part of the driver
      was broken. The work_done reporting in i40e controls not only the
      reporting back to the napi logic but also the setting of the interrupt
      throttling logic. When Tx or Rx reports that it has more to do,
      interrupts are throttled or coalesced and when they both report that
      they are done, interrupts are armed right away. If the wrong work_done
      value is returned, the logic will start to throttle interrupts in a
      situation where it should have just enabled them. This leads to the
      undesired batching behavior seen in user-space.
      
      Fix this by returning the correct boolean value from the Tx xsk
      zero-copy path. Return true if there is nothing to do or if we got
      fewer packets to process than we asked for. Return false if we got as
      many packets as the budget since there might be more packets we can
      process.
      
      Fixes: 3106c580 ("i40e: Use batched xsk Tx interfaces to increase performance")
      Reported-by: NSreedevi Joshi <sreedevi.joshi@intel.com>
      Signed-off-by: NMagnus Karlsson <magnus.karlsson@intel.com>
      Acked-by: NMaciej Fijalkowski <maciej.fijalkowski@intel.com>
      Tested-by: NKiran Bhandare <kiranx.bhandare@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      528060ef
  11. 24 3月, 2021 1 次提交
  12. 16 3月, 2021 1 次提交
  13. 20 2月, 2021 1 次提交
    • N
      i40e: Fix endianness conversions · b32cddd2
      Norbert Ciosek 提交于
      Fixes the following sparse warnings:
      i40e_main.c:5953:32: warning: cast from restricted __le16
      i40e_main.c:8008:29: warning: incorrect type in assignment (different base types)
      i40e_main.c:8008:29:    expected unsigned int [assigned] [usertype] ipa
      i40e_main.c:8008:29:    got restricted __le32 [usertype]
      i40e_main.c:8008:29: warning: incorrect type in assignment (different base types)
      i40e_main.c:8008:29:    expected unsigned int [assigned] [usertype] ipa
      i40e_main.c:8008:29:    got restricted __le32 [usertype]
      i40e_txrx.c:1950:59: warning: incorrect type in initializer (different base types)
      i40e_txrx.c:1950:59:    expected unsigned short [usertype] vlan_tag
      i40e_txrx.c:1950:59:    got restricted __le16 [usertype] l2tag1
      i40e_txrx.c:1953:40: warning: cast to restricted __le16
      i40e_xsk.c:448:38: warning: invalid assignment: |=
      i40e_xsk.c:448:38:    left side has type restricted __le64
      i40e_xsk.c:448:38:    right side has type int
      
      Fixes: 2f4b411a ("i40e: Enable cloud filters via tc-flower")
      Fixes: 2a508c64 ("i40e: fix VLAN.TCI == 0 RX HW offload")
      Fixes: 3106c580 ("i40e: Use batched xsk Tx interfaces to increase performance")
      Fixes: 8f88b303 ("i40e: Add infrastructure for queue channel support")
      Signed-off-by: NNorbert Ciosek <norbertx.ciosek@intel.com>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      b32cddd2
  14. 13 2月, 2021 1 次提交
  15. 09 2月, 2021 4 次提交
  16. 14 1月, 2021 1 次提交
  17. 17 12月, 2020 1 次提交
    • B
      i40e, xsk: clear the status bits for the next_to_use descriptor · 64050b5b
      Björn Töpel 提交于
      On the Rx side, the next_to_use index points to the next item in the
      HW ring to be refilled/allocated, and next_to_clean points to the next
      item to potentially be processed.
      
      When the HW Rx ring is fully refilled, i.e. no packets has been
      processed, the next_to_use will be next_to_clean - 1. When the ring is
      fully processed next_to_clean will be equal to next_to_use. The latter
      case is where a bug is triggered.
      
      If the next_to_use bits are not cleared, and the "fully processed"
      state is entered, a stale descriptor can be processed.
      
      The skb-path correctly clear the status bit for the next_to_use
      descriptor, but the AF_XDP zero-copy path did not do that.
      
      This change adds the status bits clearing of the next_to_use
      descriptor.
      
      Fixes: 3b4f0b66 ("i40e, xsk: Migrate to new MEM_TYPE_XSK_BUFF_POOL")
      Signed-off-by: NBjörn Töpel <bjorn.topel@intel.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      64050b5b
  18. 25 11月, 2020 1 次提交
  19. 18 11月, 2020 2 次提交
  20. 11 11月, 2020 1 次提交
  21. 15 9月, 2020 2 次提交
  22. 01 9月, 2020 3 次提交
  23. 02 7月, 2020 3 次提交
  24. 29 5月, 2020 1 次提交
  25. 22 5月, 2020 4 次提交
  26. 15 5月, 2020 1 次提交