Merge branch '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue
Tony Nguyen says:
====================
1GbE Intel Wired LAN Driver Updates 2021-05-20
This series contains updates to igc driver only.
Andre Guedes says:
This series adds AF_XDP zero-copy feature to igc driver.
The initial patches do some code refactoring, preparing the code base to
land the AF_XDP zero-copy feature, avoiding code duplications. The last
patches of the series are the ones implementing the feature.
The last patch which indeed implements AF_XDP zero-copy support was
originally way too lengthy so, for the sake of code review, I broke it
up into two patches: one adding support for the RX functionality and the
other one adding TX support.
---
v2:
Patch 8/9 - "igc: Enable RX via AF_XDP zero-copy"
* In XDP_PASS flow, copy metadata too into the skb.
* When HW timestamp is added by the NIC, after copying it into
a local variable, update xdp_buff->data_meta so that
metadata length when XDP program is called 0.
* In igc_xdp_enable_pool(), call xsk_pool_dma_unmap() on
failure.
Known issues:
When an XDP application is running in Tx-Only mode with Zero-Copy
enabled, it is not expected to add the frames to the fill-queue. I have
noticed the following two issues in this scenario:
- If XDP_USE_NEED_WAKEUP flag is not set by application, igc_poll()
will go into infinite loop because the buffer allocation resulting
in igc_clean_rx_irq_zc() indicating that all work is not done and NAPI
should keep polling. This does not occur if XDP_USE_NEED_WAKEUP
flag is set.
- Since there are no buffers allocated by userspace for the fill
queue, there is no memory allocated for the NIC to copy the data
to. If the packet received is destined to the hardware queue where
XDP application is running, no packets are received even on other
queues.
Both these issues can be mitigated by adding a few frames to the
fill queue. The second issue can also be mitigated by making sure no
packets are being received on the hardware queue where Rx is running.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Showing
Please register or sign in to comment