From: "Michael S. Tsirkin" <mst@redhat.com>
To: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: virtio-dev@lists.oasis-open.org, jasowang@redhat.com
Subject: [virtio-dev] Re: [PATCH] virtio-net: support reset queue
Date: Wed, 9 Feb 2022 04:23:17 -0500 [thread overview]
Message-ID: <20220209042121-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20220209090158.49162-1-xuanzhuo@linux.alibaba.com>
On Wed, Feb 09, 2022 at 05:01:58PM +0800, Xuan Zhuo wrote:
> This patch defines some requirements for virtio-net to support reset
> queues.
>
> Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> ---
> conformance.tex | 2 ++
> content.tex | 19 +++++++++++++++++++
> 2 files changed, 21 insertions(+)
>
> diff --git a/conformance.tex b/conformance.tex
> index 42f8537..52b4879 100644
> --- a/conformance.tex
> +++ b/conformance.tex
> @@ -136,6 +136,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Packet Transmission}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Setting Up Receive Buffers}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Processing of Incoming Packets}
> +\item \ref{drivernormative:Device Types / Network Device / Device Operation / Reset Virtqueue}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Setting MAC Address Filtering}
> \item \ref{drivernormative:Device Types / Network Device / Device Operation / Control Virtqueue / Gratuitous Packet Sending}
> @@ -396,6 +397,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Packet Transmission}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Setting Up Receive Buffers}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Processing of Incoming Packets}
> +\item \ref{devicenormative:Device Types / Network Device / Device Operation / Reset Virtqueue}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Setting MAC Address Filtering}
> \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Gratuitous Packet Sending}
> diff --git a/content.tex b/content.tex
> index c6f116c..ce8e37a 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -4000,6 +4000,25 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
> #define VIRTIO_NET_HASH_REPORT_UDPv6_EX 9
> \end{lstlisting}
>
> +\subsubsection{Reset Virtqueue}\label{sec:Device Types / Network Device / Device Operation / Reset Virtqueue}
> +
> +The receive and transmission virtqueues can implement reset based on Virtqueue
> +Reset (See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}).
> +
> +\drivernormative{\paragraph}{Gratuitous Packet Sending}{Device Types / Network Device / Device Operation / Reset Virtqueue}
> +
> +The driver MUST NOT reset the control virtqueue.
Why not though? I am guessing if it does and command is in
progress, it won't know if it completed. So it's safest to retry
then? Reset as a way to recover from a VQ error seems useful for CVQ,
I don't like disabling it like this.
Besides, it's probably too late to make this change for 1.2 ...
> +
> +\devicenormative{\paragraph}{Gratuitous Packet Sending}{Device Types / Network Device / Device Operation / Reset Virtqueue}
> +
> +After automatic receive steering or RSS receive steering has completed the
> +selection of the queue, if the destination receive queue is in reset state,
> +the device MUST re-select a different random queue. If all receive queues are in
> +reset state, the device can drop the packet.
> +
> +A virtio-net device MUST support the above requirements in order to support
> +VIRTIO_F_RING_RESET.
> +
This is more a quality of implementation issue, no? So I'd say SHOULD
here.
> \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue}
>
> The driver uses the control virtqueue (if VIRTIO_NET_F_CTRL_VQ is
> --
> 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
next prev parent reply other threads:[~2022-02-09 9:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-09 9:01 [virtio-dev] [PATCH] virtio-net: support reset queue Xuan Zhuo
2022-02-09 9:23 ` Michael S. Tsirkin [this message]
2022-02-09 11:27 ` [virtio-dev] " 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=20220209042121-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=jasowang@redhat.com \
--cc=virtio-dev@lists.oasis-open.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.