On Fri, Jun 12, 2026 at 2:40 AM Maciej Fijalkowski
<[email protected]> wrote:
>
> On Thu, Jun 11, 2026 at 03:12:39PM +0800, [email protected] wrote:
> > From: Menglong Dong <[email protected]>
> >
> > For now, we use sk_busy_loop() in __xsk_sendmsg() to send the data in tx
> > ring. The sk_busy_loop() will poll on the target NAPI. However, for the
> > nic driver that support the tx napi, such as virtio-net, it can't schedule
> > the tx NAPI, but only the rx NAPI. If we enable the busy_poll for xsk and
> > use virtio-net, we can't send data, as the rx NAPI in virtio-net doesn't
> > handle the packet sending.
>
> Am I reading this right that you decided to break busy-poll support for
> zero-copy drivers that happen to handle transmit side from Rx NAPI context
> in favor of supporting virtio-net?

Oh, nop. This series only has an impact for virtio-net. For the other
driver, the logic doesn't change.

I added a "tx_napi" field to struct nap_struct. For now, only virtio-net
will initialize it, as only virtio-net has the "tx napi".

In __napi_busy_loop(), we will use the napi->tx_napi, if it is not NULL
and we are in the tx code path(sk_tx_busy_loop), instead of napi.

Thanks!
Menglong Dong

>
> >
> > Fix this by introduce the sk_tx_busy_loop(), which will poll on the tx
> > NAPI if available. To get the tx NAPI from the napi_id, we add the
> > "tx_napi" field to napi_struct, which is ugly :/
> >
> > Another choice is to call virtnet_xsk_xmit() in virtnet_poll() too. But
> > this a little contradict the design of tx NAPI.
> >
> > Menglong Dong (3):
> >   net: busy-poll: introduce sk_tx_busy_loop()
> >   virtio_net: initialize napi.tx_napi in virtnet_alloc_queues()
> >   xsk: replace sk_busy_loop with sk_tx_busy_loop in __xsk_sendmsg()
> >
> >  drivers/net/virtio_net.c  |  1 +
> >  include/linux/netdevice.h |  1 +
> >  include/net/busy_poll.h   | 41 ++++++++++++++++++++++++++++++++++++---
> >  net/core/dev.c            | 23 +++++-----------------
> >  net/xdp/xsk.c             |  2 +-
> >  5 files changed, 46 insertions(+), 22 deletions(-)
> >
> > --
> > 2.54.0
> >

Reply via email to