On Wed, Jun 17, 2026 at 5:40 PM Maciej Fijalkowski <[email protected]> wrote: > > 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.
As far as I know, since I use TCP as the userspace protocol, I don't have any idea on how we can apply this. It seems you've got the requirement in the real world? Interesting. Thanks, Jason > > > > > > > > > Third, this series does not apply. > > > > Ah, I'll rebase this series if a V2 is acceptable. > > > > Thanks! > > Menglong Dong > > > > > > > > > > > > > > > >
