From: Menglong Dong <menglong.dong@linux.dev>
To: menglong8.dong@gmail.com, Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: mst@redhat.com, jasowang@redhat.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, minhquangbui99@gmail.com,
kerneljasonxing@gmail.com, netdev@vger.kernel.org,
virtualization@lists.linux.dev, linux-kernel@vger.kernel.org,
eperezma@redhat.com
Subject: Re: [PATCH net-next v2 1/2] virtio_net: xsk: fix race in rx wake up
Date: Tue, 16 Jun 2026 09:48:28 +0800 [thread overview]
Message-ID: <y6i9tzXeQS-8Gft2xqLmIQ@linux.dev> (raw)
In-Reply-To: <1781491685.0613394-1-xuanzhuo@linux.alibaba.com>
On 2026/6/15 10:48 Xuan Zhuo <xuanzhuo@linux.alibaba.com> write:
> On Thu, 11 Jun 2026 10:56:43 +0800, menglong8.dong@gmail.com wrote:
> > From: Menglong Dong <dongml2@chinatelecom.cn>
> >
> > During packet receiving in virtio-net, the rq can be empty, which means
> > "rq->vq->num_free == virtqueue_get_vring_size(rq->vq)", in
> > virtnet_add_recvbuf_xsk(), if we are using xsk. Meanwhile, the fill ring
> > can be empty too, which means we can't allocate anything from
> > xsk_buff_alloc_batch(). Then, we will set the XDP_RING_NEED_WAKEUP flag.
> >
[...]
> >
> > + need_wakeup = xsk_uses_need_wakeup(pool);
> > xsk_buffs = rq->xsk_buffs;
> >
> > + /* If both rq->vq and fill ring are empty, and then the user submit
> > + * all the chunks to the fill ring and check the wake up flag
> > + * after xsk_buff_alloc_batch() and before xsk_set_rx_need_wakeup(),
> > + * we will lose the chance to wake up the rx napi, so we have to
> > + * set the need_wakeup flag here.
> > + */
> > + if (need_wakeup && virtqueue_get_vring_size(rq->vq) == rq->vq->num_free)
> > + xsk_set_rx_need_wakeup(pool);
>
> Is Condition A here too strict? We should trigger the wakeup under a wider range
> of scenarios.
Hi, Xuan. Thinks for your reviewing :)
The logic here is a addition logic to the origin wake up logic, which I planed
to fix a race condition. However, this race condition seems not likely to happen,
as we discussed in this thread:
https://lore.kernel.org/netdev/rHZz5_ylT4WggoZ-Ic2Q4w@linux.dev/
So this patch is not necessary, and I'll send the 2nd patch standalone.
Thanks!
Menglong Dong
>
> > +
> > num = xsk_buff_alloc_batch(pool, xsk_buffs, rq->vq->num_free);
> > if (!num) {
> > - if (xsk_uses_need_wakeup(pool)) {
> > + if (need_wakeup) {
> > xsk_set_rx_need_wakeup(pool);
> > /* Return 0 instead of -ENOMEM so that NAPI is
> > * descheduled.
> > @@ -1341,8 +1352,6 @@ static int virtnet_add_recvbuf_xsk(struct virtnet_info *vi, struct receive_queue
> > }
> >
> > return -ENOMEM;
> > - } else {
> > - xsk_clear_rx_need_wakeup(pool);
> > }
> >
> > len = xsk_pool_get_rx_frame_size(pool) + vi->hdr_len;
> > @@ -1363,6 +1372,16 @@ static int virtnet_add_recvbuf_xsk(struct virtnet_info *vi, struct receive_queue
> > goto err;
> > }
> >
> > + if (need_wakeup) {
> > + if (rq->vq->num_free)
> > + /* We have free buffers, so we'd better wake up the
> > + * rx napi as soon as possible.
> > + */
> > + xsk_set_rx_need_wakeup(pool);
>
> Is the purpose of waking up RX NAPI to invoke try_fill_recv? However,
> virtnet_poll does not call try_fill_recv directly. it is done
> conditionally.
>
> Thanks.
>
>
> > + else
> > + xsk_clear_rx_need_wakeup(pool);
> > + }
> > +
> > return num;
> >
> > err:
> > --
> > 2.54.0
> >
>
>
next prev parent reply other threads:[~2026-06-16 1:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 2:56 [PATCH net-next v2 0/2] virtio_net: xsk: rx and tx wake up menglong8.dong
2026-06-11 2:56 ` [PATCH net-next v2 1/2] virtio_net: xsk: fix race in rx " menglong8.dong
2026-06-11 16:24 ` Bui Quang Minh
2026-06-13 12:26 ` Menglong Dong
2026-06-15 2:48 ` Xuan Zhuo
2026-06-16 1:48 ` Menglong Dong [this message]
2026-06-11 2:56 ` [PATCH net-next v2 2/2] virtio-net: xsk: support tx " menglong8.dong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=y6i9tzXeQS-8Gft2xqLmIQ@linux.dev \
--to=menglong.dong@linux.dev \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=kerneljasonxing@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=menglong8.dong@gmail.com \
--cc=minhquangbui99@gmail.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox