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. > > Third, this series does not apply. Ah, I'll rebase this series if a V2 is acceptable. Thanks! Menglong Dong > >
