All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
To: Jason Wang <jasowang@redhat.com>
Cc: virtio-comment@lists.oasis-open.org,
	virtio-comment@lists.oasis-open.org,
	virtio-dev@lists.oasis-open.org
Subject: Re: [virtio-dev] [PATCH] virtio: introduce VIRTIO_F_RING_RESET for reset queue
Date: Fri, 27 Aug 2021 11:45:12 +0800	[thread overview]
Message-ID: <1630035912.9108565-1-xuanzhuo@linux.alibaba.com> (raw)
In-Reply-To: <5d52037a-8755-5ff8-9a7b-3a383017a5cf@redhat.com>

On Fri, 27 Aug 2021 11:41:11 +0800, Jason Wang <jasowang@redhat.com> wrote:
>
> 在 2021/8/27 上午11:18, Xuan Zhuo 写道:
> > On Thu, 26 Aug 2021 12:32:34 +0800, Jason Wang <jasowang@redhat.com> wrote:
> >> 在 2021/8/23 下午4:28, Xuan Zhuo 写道:
> >>> cc jasowang@redhat.com
> >>>
> >>> On Fri, 13 Aug 2021 10:31:05 +0800, Xuan Zhuo <xuanzhuo@linux.alibaba.com> wrote:
> >>>> This patch allows the driver to reset a queue individually.
> >>>>
> >>>> This is very common on general network equipment. By disabling a queue,
> >>>> you can quickly reclaim the buffer currently on the queue. If necessary,
> >>>> we can reinitialize the queue separately.
> >>>>
> >>>> For example, when virtio-net implements support for AF_XDP, we need to
> >>>> disable a queue to release all the original buffers when AF_XDP setup.
> >>>> And quickly release all the AF_XDP buffers that have been placed in the
> >>>> queue when AF_XDP exits.
> >>>>
> >>>> Since mmio's QueueReady allows setting 0 to stop the queue, there is no
> >>>> need to distinguish whether VIRTIO_F_RING_RESET is negotiated.
> >>>>
> >>>> Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> >>>> ---
> >>>>    content.tex | 11 ++++++++++-
> >>>>    1 file changed, 10 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/content.tex b/content.tex
> >>>> index 7cec1c3..70a9765 100644
> >>>> --- a/content.tex
> >>>> +++ b/content.tex
> >>>> @@ -1001,7 +1001,13 @@ \subsubsection{Common configuration structure layout}\label{sec:Virtio Transport
> >>>>    After writing 0 to \field{device_status}, the driver MUST wait for a read of
> >>>>    \field{device_status} to return 0 before reinitializing the device.
> >>>>
> >>>> -The driver MUST NOT write a 0 to \field{queue_enable}.
> >>>> +If the VIRTIO_F_RING_RESET feature bit is not negotiated,
> >>>> +the driver MUST NOT write a 0 to \field{queue_enable}.
> >>>> +
> >>>> +Otherwise, if the VIRTIO_F_RING_RESET feature bit is negotiated,
> >>>> +the driver can stop using the queue by writing a 0 to \field{queue_enable} and
> >>>> +MUST read the value back to ensure synchronization. Then optionally re-enable
> >>>> +the queue.
> >>
> >>
> >> So I think we need to clarify what did "stop" mean here. Since you're
> >> use "RESET" in the feature I guess the virtqueue state is also reset.
> >> That's fine but I'm not sure if MMIO has the similar semantic.
> >>
> >> E.g is the virtqueue state preserved during a stop and resume?
> >    "To stop using the queue the driver MUST write zero (0x0) to this QueueReady
> >    and MUST read the value back to ensure synchronization."
> >
> > Judging from the description of the spec, the more emphasis is on the stop of
> > the queue. It does not express whether the queue can be re-enabled.
>
>
> Yes.
>
>
> >
> > I think MMIO also adds the judgment for VIRTIO_F_RING_RESET here. If this
> > function is successfully negotiated, then MMIO also supports queue reset,
> > otherwise MMIO only supports stop queue.
> >
> > The "stop" I understand means the destruction of all the states of the entire
> > queue and the release of memory. Re-enable means reallocating the memory as when
> > the device is initialized, and synchronizing this information to the device.
> > I will improve this part of the information in the next version.
> >
> > Regarding the description of the state during a stop and resume, I will add it
> > in the next version.
>
>
> A question regarding to the semantic of "resume". I guess it means the
> virtqueue will start from e.g avail index 0?

Yes.

Thanks.

>
> Thanks
>
>
> >
> > Thanks.
> >
> >> Thanks
> >>
> >>
> >>>>    \subsubsection{Notification structure layout}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Notification capability}
> >>>>
> >>>> @@ -6672,6 +6678,9 @@ \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
> >>>>      transport specific.
> >>>>      For more details about driver notifications over PCI see \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Available Buffer Notifications}.
> >>>>
> >>>> +  \item[VIRTIO_F_RING_RESET(40)] This feature indicates
> >>>> +  that the driver can reset a queue individually.
> >>>> +
> >>>>    \end{description}
> >>>>
> >>>>    \drivernormative{\section}{Reserved Feature Bits}{Reserved Feature Bits}
> >>>> --
> >>>> 2.31.0
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> >>>> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> >>>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2021-08-27  3:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1629707299.9152007-1-xuanzhuo@linux.alibaba.com>
2021-08-26  4:32 ` [virtio-comment] Re: [virtio-dev] [PATCH] virtio: introduce VIRTIO_F_RING_RESET for reset queue Jason Wang
2021-08-27  3:18   ` Xuan Zhuo
2021-08-27  3:41     ` [virtio-comment] " Jason Wang
2021-08-27  3:45       ` Xuan Zhuo [this message]
2021-09-16  7:53 Xuan Zhuo
  -- strict thread matches above, loose matches on Subject: below --
2021-08-13  2:31 Xuan Zhuo

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=1630035912.9108565-1-xuanzhuo@linux.alibaba.com \
    --to=xuanzhuo@linux.alibaba.com \
    --cc=jasowang@redhat.com \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=virtio-dev@lists.oasis-open.org \
    /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.