From: "Michael S. Tsirkin" <mst@redhat.com>
To: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: qemu-devel@nongnu.org, Jason Wang <jasowang@redhat.com>,
Alexander Bulekov <alxndr@bu.edu>
Subject: Re: [PATCH v1 2/2] virtio-net: virtio_net_flush_tx() check for per-queue reset
Date: Sun, 29 Jan 2023 07:15:47 -0500 [thread overview]
Message-ID: <20230129071154-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <1674993822.7782302-1-xuanzhuo@linux.alibaba.com>
On Sun, Jan 29, 2023 at 08:03:42PM +0800, Xuan Zhuo wrote:
> On Sun, 29 Jan 2023 06:57:29 -0500, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Sun, Jan 29, 2023 at 04:23:08PM +0800, Xuan Zhuo wrote:
> > > On Sun, 29 Jan 2023 03:12:12 -0500, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > > On Sun, Jan 29, 2023 at 03:28:28PM +0800, Xuan Zhuo wrote:
> > > > > On Sun, 29 Jan 2023 02:25:43 -0500, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > > > > On Sun, Jan 29, 2023 at 10:51:50AM +0800, Xuan Zhuo wrote:
> > > > > > > Check whether it is per-queue reset state in virtio_net_flush_tx().
> > > > > > >
> > > > > > > Before per-queue reset, we need to recover async tx resources. At this
> > > > > > > time, virtio_net_flush_tx() is called, but we should not try to send
> > > > > > > new packets, so virtio_net_flush_tx() should check the current
> > > > > > > per-queue reset state.
> > > > > >
> > > > > >
> > > > > > What does "at this time" mean here?
> > > > > > Do you in fact mean it's called from flush_or_purge_queued_packets?
> > > > >
> > > > > Yes
> > > > >
> > > > > virtio_queue_reset
> > > > > k->queue_reset
> > > > > virtio_net_queue_reset
> > > > > flush_or_purge_queued_packets
> > > > > qemu_flush_or_purge_queued_packets
> > > > > .....
> > > > > (callback) virtio_net_tx_complete
> > > > > virtio_net_flush_tx <-- here send new packet. We need stop it.
> > > > >
> > > > >
> > > > > Because it is inside the callback, I can't pass information through the stack. I
> > > > > originally thought it was a general situation, so I wanted to put it in
> > > > > struct VirtQueue.
> > > > >
> > > > > If it is not very suitable, it may be better to put it in VirtIONetQueue.
> > > > >
> > > > > Thanks.
> > > >
> > > > Hmm maybe. Another idea: isn't virtio_net_tx_complete called
> > > > with length 0 here? Are there other cases where length is 0?
> > > >
> > > >
> > > > > > What does the call stack look like?
> > > > > >
> > > > > > If yes introducing a vq state just so virtio_net_flush_tx
> > > > > > knows we are in the process of reset would be a bad idea.
> > > > > > We want something much more local, ideally on stack even ...
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Fixes: 7dc6be52 ("virtio-net: support queue reset")
> > > > > > > Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1451
> > > > > > > Reported-by: Alexander Bulekov <alxndr@bu.edu>
> > > > > > > Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > > > > > ---
> > > > > > > hw/net/virtio-net.c | 3 ++-
> > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > > > > > > index 3ae909041a..fba6451a50 100644
> > > > > > > --- a/hw/net/virtio-net.c
> > > > > > > +++ b/hw/net/virtio-net.c
> > > > > > > @@ -2627,7 +2627,8 @@ static int32_t virtio_net_flush_tx(VirtIONetQueue *q)
> > > > > > > VirtQueueElement *elem;
> > > > > > > int32_t num_packets = 0;
> > > > > > > int queue_index = vq2q(virtio_get_queue_index(q->tx_vq));
> > > > > > > - if (!(vdev->status & VIRTIO_CONFIG_S_DRIVER_OK)) {
> > > > > > > + if (!(vdev->status & VIRTIO_CONFIG_S_DRIVER_OK) ||
> > > > > > > + virtio_queue_reset_state(q->tx_vq)) {
> > > >
> > > > btw this sounds like you are asking it to reset some state.
> > > >
> > > > > > > return num_packets;
> > > >
> > > > and then
> > > >
> > > > ret = virtio_net_flush_tx(q);
> > > > if (ret >= n->tx_burst)
> > > >
> > > >
> > > > will reschedule automatically won't it?
> > > >
> > > > also why check in virtio_net_flush_tx and not virtio_net_tx_complete?
> > >
> > > virtio_net_flush_tx may been called by timer.
> > >
> > > Thanks.
> >
> > timer won't run while flush_or_purge_queued_packets is in progress.
>
> Is timer not executed during the VMEXIT process? Otherwise, we still have to
> consider that after the flush_or_purge_queued_packets, this process before the
> structure is cleared.
void virtio_queue_reset(VirtIODevice *vdev, uint32_t queue_index)
{
VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev);
if (k->queue_reset) {
k->queue_reset(vdev, queue_index);
}
__virtio_queue_reset(vdev, queue_index);
}
No timers do not run between k->queue_reset and __virtio_queue_reset.
> Even if it can be processed in virtio_net_tx_complete, is there any good way?
> This is a callback, it is not convenient to pass the parameters.
>
> Thanks
How about checking that length is 0?
>
> >
> > > >
> > > >
> > > > > > > }
> > > > > > >
> > > > > > > --
> > > > > > > 2.32.0.3.g01195cf9f
> > > > > >
> > > >
> >
next prev parent reply other threads:[~2023-01-29 12:16 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-29 2:51 [PATCH v1 0/2] virtio: fix for assertion failure: virtio_net_get_subqueue(nc)->async_tx.elem failed Xuan Zhuo
2023-01-29 2:51 ` [PATCH v1 1/2] virtio: struct VirtQueue introduce reset Xuan Zhuo
2023-01-29 7:12 ` Michael S. Tsirkin
2023-01-29 7:15 ` Xuan Zhuo
2023-01-29 7:37 ` Michael S. Tsirkin
2023-01-29 7:39 ` Xuan Zhuo
2023-01-29 2:51 ` [PATCH v1 2/2] virtio-net: virtio_net_flush_tx() check for per-queue reset Xuan Zhuo
2023-01-29 6:23 ` Jason Wang
2023-01-29 7:43 ` Xuan Zhuo
2023-01-30 3:01 ` Jason Wang
2023-01-30 3:38 ` Xuan Zhuo
2023-01-30 3:53 ` Jason Wang
2023-01-30 5:50 ` Michael S. Tsirkin
2023-01-30 8:41 ` Jason Wang
2023-01-29 7:25 ` Michael S. Tsirkin
2023-01-29 7:28 ` Xuan Zhuo
2023-01-29 8:12 ` Michael S. Tsirkin
2023-01-29 8:23 ` Xuan Zhuo
2023-01-29 11:57 ` Michael S. Tsirkin
2023-01-29 12:03 ` Xuan Zhuo
2023-01-29 12:15 ` Michael S. Tsirkin [this message]
2023-01-29 12:28 ` Xuan Zhuo
2023-01-30 2:15 ` Xuan Zhuo
2023-01-30 5:32 ` Michael S. Tsirkin
2023-01-30 7:49 ` Jason Wang
2023-01-30 7:53 ` Xuan Zhuo
2023-01-30 8:40 ` Jason Wang
2023-01-30 10:24 ` Xuan Zhuo
2023-01-31 3:27 ` Jason Wang
2023-01-31 7:17 ` Xuan Zhuo
2023-01-31 7:38 ` Xuan Zhuo
2023-01-29 7:26 ` [PATCH v1 0/2] virtio: fix for assertion failure: virtio_net_get_subqueue(nc)->async_tx.elem failed Michael S. Tsirkin
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=20230129071154-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alxndr@bu.edu \
--cc=jasowang@redhat.com \
--cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).