All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: Albert Huang <huangjie.albert@bytedance.com>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH v4] virtio_ring: interrupt disable flag updated to vq even with event_triggered is set
Date: Wed, 29 Mar 2023 12:34:26 -0400	[thread overview]
Message-ID: <20230329122852-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <1680090301.6450636-1-xuanzhuo@linux.alibaba.com>

On Wed, Mar 29, 2023 at 07:45:01PM +0800, Xuan Zhuo wrote:
> On Wed, 29 Mar 2023 18:23:00 +0800, Albert Huang <huangjie.albert@bytedance.com> wrote:
> > From: "huangjie.albert" <huangjie.albert@bytedance.com>
> >
> > in virtio_net, if we disable the napi_tx, when we triger a tx interrupt,
> > the vq->event_triggered will be set to true. It will no longer be set to
> > false. Unless we explicitly call virtqueue_enable_cb_delayed or
> > virtqueue_enable_cb_prepare.
> >
> > If we disable the napi_tx, it will only be called when the tx ring
> > buffer is relatively small.
> >
> > Because event_triggered is true. Therefore, VRING_AVAIL_F_NO_INTERRUPT or
> > VRING_PACKED_EVENT_FLAG_DISABLE will not be set. So we update
> > vring_used_event(&vq->split.vring) or vq->packed.vring.driver->off_wrap
> > every time we call virtqueue_get_buf_ctx.This bring more interruptions.
> >
> > To summarize:
> > 1) event_triggered was set to true in vring_interrupt()
> > 2) after this nothing will happen for virtqueue_disable_cb() so
> >    VRING_AVAIL_F_NO_INTERRUPT is not set in avail_flags_shadow
> > 3) virtqueue_get_buf_ctx_split() will still think the cb is enabled
> >    then it tries to publish new event
> >
> > To fix:
> > update VRING_AVAIL_F_NO_INTERRUPT or VRING_PACKED_EVENT_FLAG_DISABLE to vq
> > when we call virtqueue_disable_cb even the event_triggered is set to true.
> >
> > Tested with iperf:
> > iperf3 tcp stream:
> > vm1 -----------------> vm2
> > vm2 just receives tcp data stream from vm1, and sends the ack to vm1,
> > there are many tx interrupts in vm2.
> > but without event_triggered there are just a few tx interrupts.
> >
> > v2->v3:
> > -update the interrupt disable flag even with the event_triggered is set,
> > -instead of checking whether event_triggered is set in
> > -virtqueue_get_buf_ctx_{packed/split}, will cause the drivers  which have
> > -not called virtqueue_{enable/disable}_cb to miss notifications.
> >
> > v3->v4:
> > -remove change for
> > -"if (vq->packed.event_flags_shadow != VRING_PACKED_EVENT_FLAG_DISABLE)"
> > -in virtqueue_disable_cb_packed
> >
> > Fixes: 8d622d21d248 ("virtio: fix up virtio_disable_cb")
> 
> Hi Michael,
> 
> I want to know what the purpose of this patch("virtio: fix up virtio_disable_cb")
> is. I re-review this patch. I didn't understand what the purpose of this
> patches. Does it reduce one write to vring_used_event(&vq->split.vring) ?
> 
> Thanks.

Are you asking why I applied 8d622d21d248 ("virtio: fix up
virtio_disable_cb")?

It was a prerequisite to fixing interrupt storms we saw in the field previously.

See Message-ID: <20210413011508-mutt-send-email-mst@kernel.org>
for the bug report and Message-ID: <20210413054733.36363-1-mst@redhat.com>
for the original patchset fixing it.


> 
> > Signed-off-by: huangjie.albert <huangjie.albert@bytedance.com>
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > ---
> >  drivers/virtio/virtio_ring.c | 22 ++++++++++++++++------
> >  1 file changed, 16 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index cbeeea1b0439..ec7ab8e04846 100644
> > --- a/drivers/virtio/virtio_ring.c
> > +++ b/drivers/virtio/virtio_ring.c
> > @@ -931,6 +931,14 @@ static void virtqueue_disable_cb_split(struct virtqueue *_vq)
> >
> >  	if (!(vq->split.avail_flags_shadow & VRING_AVAIL_F_NO_INTERRUPT)) {
> >  		vq->split.avail_flags_shadow |= VRING_AVAIL_F_NO_INTERRUPT;
> > +
> > +		/*
> > +		 * If device triggered an event already it won't trigger one again:
> > +		 * no need to disable.
> > +		 */
> > +		if (vq->event_triggered)
> > +			return;
> > +
> >  		if (vq->event)
> >  			/* TODO: this is a hack. Figure out a cleaner value to write. */
> >  			vring_used_event(&vq->split.vring) = 0x0;
> > @@ -1761,6 +1769,14 @@ static void virtqueue_disable_cb_packed(struct virtqueue *_vq)
> >
> >  	if (vq->packed.event_flags_shadow != VRING_PACKED_EVENT_FLAG_DISABLE) {
> >  		vq->packed.event_flags_shadow = VRING_PACKED_EVENT_FLAG_DISABLE;
> > +
> > +		/*
> > +		 * If device triggered an event already it won't trigger one again:
> > +		 * no need to disable.
> > +		 */
> > +		if (vq->event_triggered)
> > +			return;
> > +
> >  		vq->packed.vring.driver->flags =
> >  			cpu_to_le16(vq->packed.event_flags_shadow);
> >  	}
> > @@ -2462,12 +2478,6 @@ void virtqueue_disable_cb(struct virtqueue *_vq)
> >  {
> >  	struct vring_virtqueue *vq = to_vvq(_vq);
> >
> > -	/* If device triggered an event already it won't trigger one again:
> > -	 * no need to disable.
> > -	 */
> > -	if (vq->event_triggered)
> > -		return;
> > -
> >  	if (vq->packed_ring)
> >  		virtqueue_disable_cb_packed(_vq);
> >  	else
> > --
> > 2.20.1
> >

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: Albert Huang <huangjie.albert@bytedance.com>,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, Jason Wang <jasowang@redhat.com>
Subject: Re: [PATCH v4] virtio_ring: interrupt disable flag updated to vq even with event_triggered is set
Date: Wed, 29 Mar 2023 12:34:26 -0400	[thread overview]
Message-ID: <20230329122852-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <1680090301.6450636-1-xuanzhuo@linux.alibaba.com>

On Wed, Mar 29, 2023 at 07:45:01PM +0800, Xuan Zhuo wrote:
> On Wed, 29 Mar 2023 18:23:00 +0800, Albert Huang <huangjie.albert@bytedance.com> wrote:
> > From: "huangjie.albert" <huangjie.albert@bytedance.com>
> >
> > in virtio_net, if we disable the napi_tx, when we triger a tx interrupt,
> > the vq->event_triggered will be set to true. It will no longer be set to
> > false. Unless we explicitly call virtqueue_enable_cb_delayed or
> > virtqueue_enable_cb_prepare.
> >
> > If we disable the napi_tx, it will only be called when the tx ring
> > buffer is relatively small.
> >
> > Because event_triggered is true. Therefore, VRING_AVAIL_F_NO_INTERRUPT or
> > VRING_PACKED_EVENT_FLAG_DISABLE will not be set. So we update
> > vring_used_event(&vq->split.vring) or vq->packed.vring.driver->off_wrap
> > every time we call virtqueue_get_buf_ctx.This bring more interruptions.
> >
> > To summarize:
> > 1) event_triggered was set to true in vring_interrupt()
> > 2) after this nothing will happen for virtqueue_disable_cb() so
> >    VRING_AVAIL_F_NO_INTERRUPT is not set in avail_flags_shadow
> > 3) virtqueue_get_buf_ctx_split() will still think the cb is enabled
> >    then it tries to publish new event
> >
> > To fix:
> > update VRING_AVAIL_F_NO_INTERRUPT or VRING_PACKED_EVENT_FLAG_DISABLE to vq
> > when we call virtqueue_disable_cb even the event_triggered is set to true.
> >
> > Tested with iperf:
> > iperf3 tcp stream:
> > vm1 -----------------> vm2
> > vm2 just receives tcp data stream from vm1, and sends the ack to vm1,
> > there are many tx interrupts in vm2.
> > but without event_triggered there are just a few tx interrupts.
> >
> > v2->v3:
> > -update the interrupt disable flag even with the event_triggered is set,
> > -instead of checking whether event_triggered is set in
> > -virtqueue_get_buf_ctx_{packed/split}, will cause the drivers  which have
> > -not called virtqueue_{enable/disable}_cb to miss notifications.
> >
> > v3->v4:
> > -remove change for
> > -"if (vq->packed.event_flags_shadow != VRING_PACKED_EVENT_FLAG_DISABLE)"
> > -in virtqueue_disable_cb_packed
> >
> > Fixes: 8d622d21d248 ("virtio: fix up virtio_disable_cb")
> 
> Hi Michael,
> 
> I want to know what the purpose of this patch("virtio: fix up virtio_disable_cb")
> is. I re-review this patch. I didn't understand what the purpose of this
> patches. Does it reduce one write to vring_used_event(&vq->split.vring) ?
> 
> Thanks.

Are you asking why I applied 8d622d21d248 ("virtio: fix up
virtio_disable_cb")?

It was a prerequisite to fixing interrupt storms we saw in the field previously.

See Message-ID: <20210413011508-mutt-send-email-mst@kernel.org>
for the bug report and Message-ID: <20210413054733.36363-1-mst@redhat.com>
for the original patchset fixing it.


> 
> > Signed-off-by: huangjie.albert <huangjie.albert@bytedance.com>
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > ---
> >  drivers/virtio/virtio_ring.c | 22 ++++++++++++++++------
> >  1 file changed, 16 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index cbeeea1b0439..ec7ab8e04846 100644
> > --- a/drivers/virtio/virtio_ring.c
> > +++ b/drivers/virtio/virtio_ring.c
> > @@ -931,6 +931,14 @@ static void virtqueue_disable_cb_split(struct virtqueue *_vq)
> >
> >  	if (!(vq->split.avail_flags_shadow & VRING_AVAIL_F_NO_INTERRUPT)) {
> >  		vq->split.avail_flags_shadow |= VRING_AVAIL_F_NO_INTERRUPT;
> > +
> > +		/*
> > +		 * If device triggered an event already it won't trigger one again:
> > +		 * no need to disable.
> > +		 */
> > +		if (vq->event_triggered)
> > +			return;
> > +
> >  		if (vq->event)
> >  			/* TODO: this is a hack. Figure out a cleaner value to write. */
> >  			vring_used_event(&vq->split.vring) = 0x0;
> > @@ -1761,6 +1769,14 @@ static void virtqueue_disable_cb_packed(struct virtqueue *_vq)
> >
> >  	if (vq->packed.event_flags_shadow != VRING_PACKED_EVENT_FLAG_DISABLE) {
> >  		vq->packed.event_flags_shadow = VRING_PACKED_EVENT_FLAG_DISABLE;
> > +
> > +		/*
> > +		 * If device triggered an event already it won't trigger one again:
> > +		 * no need to disable.
> > +		 */
> > +		if (vq->event_triggered)
> > +			return;
> > +
> >  		vq->packed.vring.driver->flags =
> >  			cpu_to_le16(vq->packed.event_flags_shadow);
> >  	}
> > @@ -2462,12 +2478,6 @@ void virtqueue_disable_cb(struct virtqueue *_vq)
> >  {
> >  	struct vring_virtqueue *vq = to_vvq(_vq);
> >
> > -	/* If device triggered an event already it won't trigger one again:
> > -	 * no need to disable.
> > -	 */
> > -	if (vq->event_triggered)
> > -		return;
> > -
> >  	if (vq->packed_ring)
> >  		virtqueue_disable_cb_packed(_vq);
> >  	else
> > --
> > 2.20.1
> >


  reply	other threads:[~2023-03-29 16:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-29 10:23 [PATCH v4] virtio_ring: interrupt disable flag updated to vq even with event_triggered is set Albert Huang
2023-03-29 11:45 ` Xuan Zhuo
2023-03-29 11:45   ` Xuan Zhuo
2023-03-29 16:34   ` Michael S. Tsirkin [this message]
2023-03-29 16:34     ` Michael S. Tsirkin
2023-03-29 16:36 ` Michael S. Tsirkin
2023-03-29 16:36   ` Michael S. Tsirkin
2023-03-29 16:40 ` Michael S. Tsirkin
2023-03-29 16:40   ` Michael S. Tsirkin
2023-03-30  2:15   ` [External] " 黄杰

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=20230329122852-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=huangjie.albert@bytedance.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.