On Sun, Jun 14, 2026 at 06:12:46PM +0800, Menglong Dong wrote: > On 2026/6/14 02:21, Jakub Kicinski wrote: > > On Thu, 11 Jun 2026 15:12:40 +0800 [email protected] wrote: > > > For now, we use sk_busy_loop() for both rx and tx path. The sk_busy_loop() > > > will call napi_busy_loop() for the specified napi_id. However, some > > > nic drivers have tx napi, such as virtio-net. In this case, sk_busy_loop() > > > doesn't work, as it can only schedule the NAPI for the rx queue. > > > > > > Therefore, introduce sk_tx_busy_loop() for the nic drivers that support tx > > > napi, which will schedule the tx napi if available. > > > > First, I thought the only difference with Tx NAPI is that it can't be > > busy polled. So if you want to poll an instance don't register it as > > a Tx one instead of adding all this "tx polling" stuff in the core? > > I see. Register the tx NAPI with netif_napi_add_config() allow us > busy poll it. But we still have two NAPI instance: rx NAPI and tx NAPI. > sk_busy_loop() can only busy poll on one of them. > > Before AF_XDP, we don't have the need to send packet via tx NAPI, which > means that we don't need to busy poll it. > > I analyst some nic drivers on the implement of AF_XDP. Some of them > will check xsk tx ring of current queue and send the data in it in the > rx NAPI, such as mlx5. Some of them will allocate a extra "rxtx" NAPI > for the AF_XDP zero-copy queue, which will poll both the data receiving > and sending. > > In the case about, they will do the data sending and receiving for the > AF_XDP in a single NAPI instance. > > However, some driver receiving the data in rx NAPI and send data in > tx NAPI for AF_XDP. In this case, we can't use sk_busy_loop() for both > rx path and tx path, as we need to wake different NAPI instance. > > > > > Second, can this problem happen for any other NIC or is it purely > > an artifact of virtio's delayed Tx completion handling? > > According to my analysis, only virtio-net and ICSSG driver have > split NAPI for AF_XDP. I don't have a ICSSG nic, but the codex tell > me that it does have the same problem. > > I'm not sure if it is a good idea to introduce the sk_tx_busy_loop(). > Maybe we can modify the driver instead by using the same NAPI > for both data sending and receiving, just like others do. The > advantage of introduce sk_tx_busy_loop() is that we can split the > data sending and receiving, which maybe more efficient.
Would be good if you back your changes by any performance numbers. I believe that drivers do tx processing via rx napi as before AF_XDP it was only about cleaning up writebacks, AF_XDP added more weight via actual tx descriptors submission. Maybe you can vibe-code virtio-net to work only with rx napi and see what are the results. Side note/question - Do you have a tx-only use case for AF_XDP ? I am planning (for a long time actually) to implement asymmetric AF_XDP sockets. Currently for ZC scenarios xsk socket occupies both rx and tx queues even when you do rx or tx only. > > > > > Third, this series does not apply. > > Ah, I'll rebase this series if a V2 is acceptable. > > Thanks! > Menglong Dong > > > > > > > > >
