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: [...] > > > > 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.
Hi, Maciej. I have not done such performance testing yet. It's a good and interesting idea to do such testing on viriot-net, and I'll do it. If there is no obvious performance differences, I'll modify virtio-net by sending data via rx napi instead. > > 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. I think this is an interesting idea, and will be helpful in some cases. I'm improving the performance of MySQL with AF_XDP. For this case, tx-only is not suitable, as data reading and writing are both needed. But for the other case, such as Redis, data reading is mostly. And in this case, I think it's a good idea to use such "tx-only" ZC AF_XDP. In my case, I don't want to occupy the whole NIC or the whole queue with AF_XDP, and the other users can use the NIC too. However, the ZC of AF_XDP has a little additional overhead to the skb in rx path, as there is an extra data copy. If such "tx-only" ZC is supported, the performance of AF_XDP is still good in the read mostly case, and doesn't have additional overhead to others too. I haven't used AF_XDP for such a "reading mostly" case yet, so I'm not sure if I'm right ;) Thanks! Menglong Dong > > > > > > > > > Third, this series does not apply. > > > > Ah, I'll rebase this series if a V2 is acceptable. > > > > Thanks! > > Menglong Dong > > > > > > > > > > > > > > > >
