1. 22 5月, 2020 3 次提交
  2. 15 5月, 2020 1 次提交
  3. 06 2月, 2020 1 次提交
  4. 21 12月, 2019 1 次提交
  5. 19 12月, 2019 1 次提交
  6. 09 11月, 2019 1 次提交
    • M
      i40e: need_wakeup flag might not be set for Tx · 70563957
      Magnus Karlsson 提交于
      The need_wakeup flag for Tx might not be set for AF_XDP sockets that
      are only used to send packets. This happens if there is at least one
      outstanding packet that has not been completed by the hardware and we
      get that corresponding completion (which will not generate an
      interrupt since interrupts are disabled in the napi poll loop) between
      the time we stopped processing the Tx completions and interrupts are
      enabled again. In this case, the need_wakeup flag will have been
      cleared at the end of the Tx completion processing as we believe we
      will get an interrupt from the outstanding completion at a later point
      in time. But if this completion interrupt occurs before interrupts
      are enable, we lose it and should at that point really have set the
      need_wakeup flag since there are no more outstanding completions that
      can generate an interrupt to continue the processing. When this
      happens, user space will see a Tx queue need_wakeup of 0 and skip
      issuing a syscall, which means will never get into the Tx processing
      again and we have a deadlock.
      
      This patch introduces a quick fix for this issue by just setting the
      need_wakeup flag for Tx to 1 all the time. I am working on a proper
      fix for this that will toggle the flag appropriately, but it is more
      challenging than I anticipated and I am afraid that this patch will
      not be completed before the merge window closes, therefore this easier
      fix for now. This fix has a negative performance impact in the range
      of 0% to 4%. Towards the higher end of the scale if you have driver
      and application on the same core and issue a lot of packets, and
      towards no negative impact if you use two cores, lower transmission
      speeds and/or a workload that also receives packets.
      Signed-off-by: NMagnus Karlsson <magnus.karlsson@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      70563957
  7. 02 11月, 2019 1 次提交
  8. 16 9月, 2019 1 次提交
  9. 12 9月, 2019 1 次提交
    • M
      i40e: fix potential RX buffer starvation for AF_XDP · 1f459bdc
      Magnus Karlsson 提交于
      When the RX rings are created they are also populated with buffers
      so that packets can be received. Usually these are kernel buffers,
      but for AF_XDP in zero-copy mode, these are user-space buffers and
      in this case the application might not have sent down any buffers
      to the driver at this point. And if no buffers are allocated at ring
      creation time, no packets can be received and no interrupts will be
      generated so the NAPI poll function that allocates buffers to the
      rings will never get executed.
      
      To rectify this, we kick the NAPI context of any queue with an
      attached AF_XDP zero-copy socket in two places in the code. Once
      after an XDP program has loaded and once after the umem is registered.
      This take care of both cases: XDP program gets loaded first then AF_XDP
      socket is created, and the reverse, AF_XDP socket is created first,
      then XDP program is loaded.
      
      Fixes: 0a714186 ("i40e: add AF_XDP zero-copy Rx support")
      Signed-off-by: NMagnus Karlsson <magnus.karlsson@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      1f459bdc
  10. 05 9月, 2019 1 次提交
  11. 31 8月, 2019 2 次提交
  12. 18 8月, 2019 2 次提交
  13. 28 6月, 2019 1 次提交
  14. 15 6月, 2019 1 次提交
  15. 02 4月, 2019 1 次提交
  16. 22 2月, 2019 1 次提交
    • M
      i40e: fix potential RX buffer starvation for AF_XDP · 14ffeb52
      Magnus Karlsson 提交于
      When the RX rings are created they are also populated with buffers
      so that packets can be received. Usually these are kernel buffers,
      but for AF_XDP in zero-copy mode, these are user-space buffers and
      in this case the application might not have sent down any buffers
      to the driver at this point. And if no buffers are allocated at ring
      creation time, no packets can be received and no interrupts will be
      generated so the NAPI poll function that allocates buffers to the
      rings will never get executed.
      
      To rectify this, we kick the NAPI context of any queue with an
      attached AF_XDP zero-copy socket in two places in the code. Once
      after an XDP program has loaded and once after the umem is registered.
      This take care of both cases: XDP program gets loaded first then AF_XDP
      socket is created, and the reverse, AF_XDP socket is created first,
      then XDP program is loaded.
      
      Fixes: 0a714186 ("i40e: add AF_XDP zero-copy Rx support")
      Signed-off-by: NMagnus Karlsson <magnus.karlsson@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      14ffeb52
  17. 15 2月, 2019 1 次提交
  18. 22 1月, 2019 1 次提交
  19. 13 12月, 2018 2 次提交
  20. 29 11月, 2018 1 次提交
  21. 26 9月, 2018 3 次提交
  22. 01 9月, 2018 2 次提交
  23. 30 8月, 2018 2 次提交
    • M
      i40e: add AF_XDP zero-copy Tx support · 1328dcdd
      Magnus Karlsson 提交于
      This patch adds zero-copy Tx support for AF_XDP sockets. It implements
      the ndo_xsk_async_xmit netdev ndo and performs all the Tx logic from a
      NAPI context. This means pulling egress packets from the Tx ring,
      placing the frames on the NIC HW descriptor ring and completing sent
      frames back to the application via the completion ring.
      
      The regular XDP Tx ring is used for AF_XDP as well. This rationale for
      this is as follows: XDP_REDIRECT guarantees mutual exclusion between
      different NAPI contexts based on CPU id. In other words, a netdev can
      XDP_REDIRECT to another netdev with a different NAPI context, since
      the operation is bound to a specific core and each core has its own
      hardware ring.
      
      As the AF_XDP Tx action is running in the same NAPI context and using
      the same ring, it will also be protected from XDP_REDIRECT actions
      with the exact same mechanism.
      
      As with AF_XDP Rx, all AF_XDP Tx specific functions are added to
      i40e_xsk.c.
      Signed-off-by: NMagnus Karlsson <magnus.karlsson@intel.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      1328dcdd
    • B
      i40e: add AF_XDP zero-copy Rx support · 0a714186
      Björn Töpel 提交于
      This patch adds zero-copy Rx support for AF_XDP sockets. Instead of
      allocating buffers of type MEM_TYPE_PAGE_SHARED, the Rx frames are
      allocated as MEM_TYPE_ZERO_COPY when AF_XDP is enabled for a certain
      queue.
      
      All AF_XDP specific functions are added to a new file, i40e_xsk.c.
      
      Note that when AF_XDP zero-copy is enabled, the XDP action XDP_PASS
      will allocate a new buffer and copy the zero-copy frame prior passing
      it to the kernel stack.
      Signed-off-by: NBjörn Töpel <bjorn.topel@intel.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      0a714186
新手
引导
客服 返回
顶部