On 2026/6/17 17:40 Maciej Fijalkowski <[email protected]> write: > 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.
According to my testing, there is no obvious performance improvement with tx napi. I'm going to implement the xsk tx queue consume in rx napi instead for virtio-net. Thanks! Menglong Dong > > 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 > > > > > > > > > > > > > > > > >
