* Re: [virtio-dev] [PATCH v4] virtio-net: support reset queue
2022-02-22 6:52 [virtio-dev] [PATCH v4] virtio-net: support reset queue Xuan Zhuo
@ 2022-04-24 3:05 ` Xuan Zhuo
2022-04-24 6:34 ` [virtio-dev] " Jason Wang
2022-04-24 6:53 ` Michael S. Tsirkin
2 siblings, 0 replies; 5+ messages in thread
From: Xuan Zhuo @ 2022-04-24 3:05 UTC (permalink / raw)
To: Xuan Zhuo; +Cc: jasowang, Michael S. Tsirkin, virtio-dev
On Tue, 22 Feb 2022 14:52:41 +0800, Xuan Zhuo <xuanzhuo@linux.alibaba.com> wrote:
> This patch defines some requirements for virtio-net to support reset
> queues.
Is there any problem with this?
Thanks.
>
> Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> ---
> content.tex | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/content.tex b/content.tex
> index c6f116c..45751f4 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -4337,6 +4337,10 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> \field{virtqueue_pairs} once it has placed the
> VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command in a used buffer.
>
> +If the destination receive queue is in reset state(See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}),
> +the device SHOULD re-select a different random queue. If all receive queues are
> +in reset state, the device MUST drop the packet.
> +
> \subparagraph{Legacy Interface: Automatic receive steering in multiqueue mode}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode / Legacy Interface: Automatic receive steering in multiqueue mode}
> When using the legacy interface, transitional devices and drivers
> MUST format \field{virtqueue_pairs}
> @@ -4425,6 +4429,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> \item Calculate the hash of the packet as defined in \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets / Hash calculation for incoming packets}.
> \item If the device did not calculate the hash for the specific packet, the device directs the packet to the receiveq specified by \field{unclassified_queue} of virtio_net_rss_config structure (value of 0 corresponds to receiveq1).
> \item Apply \field{indirection_table_mask} to the calculated hash and use the result as the index in the indirection table to get 0-based number of destination receiveq (value of 0 corresponds to receiveq1).
> +\item If the destination receive queue is in reset state(See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}), the device MUST drop the packet.
> \end{itemize}
>
> \paragraph{Offloads State Configuration}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Offloads State Configuration}
> --
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread* [virtio-dev] Re: [PATCH v4] virtio-net: support reset queue
2022-02-22 6:52 [virtio-dev] [PATCH v4] virtio-net: support reset queue Xuan Zhuo
2022-04-24 3:05 ` Xuan Zhuo
@ 2022-04-24 6:34 ` Jason Wang
2022-04-24 6:53 ` Michael S. Tsirkin
2 siblings, 0 replies; 5+ messages in thread
From: Jason Wang @ 2022-04-24 6:34 UTC (permalink / raw)
To: Xuan Zhuo, virtio-dev; +Cc: Michael S. Tsirkin
在 2022/2/22 14:52, Xuan Zhuo 写道:
> This patch defines some requirements for virtio-net to support reset
> queues.
>
> Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> ---
Reviewed-by: Jason Wang <jasowang@redhat.com>
> content.tex | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/content.tex b/content.tex
> index c6f116c..45751f4 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -4337,6 +4337,10 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> \field{virtqueue_pairs} once it has placed the
> VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command in a used buffer.
>
> +If the destination receive queue is in reset state(See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}),
> +the device SHOULD re-select a different random queue. If all receive queues are
> +in reset state, the device MUST drop the packet.
> +
> \subparagraph{Legacy Interface: Automatic receive steering in multiqueue mode}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode / Legacy Interface: Automatic receive steering in multiqueue mode}
> When using the legacy interface, transitional devices and drivers
> MUST format \field{virtqueue_pairs}
> @@ -4425,6 +4429,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> \item Calculate the hash of the packet as defined in \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets / Hash calculation for incoming packets}.
> \item If the device did not calculate the hash for the specific packet, the device directs the packet to the receiveq specified by \field{unclassified_queue} of virtio_net_rss_config structure (value of 0 corresponds to receiveq1).
> \item Apply \field{indirection_table_mask} to the calculated hash and use the result as the index in the indirection table to get 0-based number of destination receiveq (value of 0 corresponds to receiveq1).
> +\item If the destination receive queue is in reset state(See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}), the device MUST drop the packet.
> \end{itemize}
>
> \paragraph{Offloads State Configuration}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Offloads State Configuration}
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 5+ messages in thread* [virtio-dev] Re: [PATCH v4] virtio-net: support reset queue
2022-02-22 6:52 [virtio-dev] [PATCH v4] virtio-net: support reset queue Xuan Zhuo
2022-04-24 3:05 ` Xuan Zhuo
2022-04-24 6:34 ` [virtio-dev] " Jason Wang
@ 2022-04-24 6:53 ` Michael S. Tsirkin
2022-04-24 7:57 ` Xuan Zhuo
2 siblings, 1 reply; 5+ messages in thread
From: Michael S. Tsirkin @ 2022-04-24 6:53 UTC (permalink / raw)
To: Xuan Zhuo; +Cc: virtio-dev, jasowang
On Tue, Feb 22, 2022 at 02:52:41PM +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>
Suggest creating a github issue documenting that it is not defined
what the behaviour is, so we rememeber to list this as a known issue
in 1.2.
> ---
> content.tex | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/content.tex b/content.tex
> index c6f116c..45751f4 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -4337,6 +4337,10 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> \field{virtqueue_pairs} once it has placed the
> VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command in a used buffer.
>
> +If the destination receive queue is in reset state(See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}),
Should this be "a reset state"? Also, I do not see any definition of "reset state" in
the linked chapter. That chapter should really be cleaned up btw.
> +the device SHOULD re-select a different random queue.
different from what?
I suspect we want to move this:
When multiqueue is enabled by VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command, the device MUST use automatic receive steering
based on packet flow. Programming of the receive steering
classificator is implicit. After the driver transmitted a packet of a
flow on transmitqX, the device SHOULD cause incoming packets for that flow to
be steered to receiveqX. For uni-directional protocols, or where
no packets have been transmitted yet, the device MAY steer a packet
to a random queue out of the specified receiveq1\ldots receiveqn.
to a conformance chapter, and be replaced with a general description
avoiding conformance keyworkds like MUST and SHOULD.
Generally, whenever we have conformance keywords out of conformance
clauses it's a bug and source of confusion at some point.
> If all receive queues are
> +in reset state, the device MUST drop the packet.
> +
> \subparagraph{Legacy Interface: Automatic receive steering in multiqueue mode}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode / Legacy Interface: Automatic receive steering in multiqueue mode}
> When using the legacy interface, transitional devices and drivers
> MUST format \field{virtqueue_pairs}
> @@ -4425,6 +4429,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> \item Calculate the hash of the packet as defined in \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets / Hash calculation for incoming packets}.
> \item If the device did not calculate the hash for the specific packet, the device directs the packet to the receiveq specified by \field{unclassified_queue} of virtio_net_rss_config structure (value of 0 corresponds to receiveq1).
> \item Apply \field{indirection_table_mask} to the calculated hash and use the result as the index in the indirection table to get 0-based number of destination receiveq (value of 0 corresponds to receiveq1).
> +\item If the destination receive queue is in reset state(See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}), the device MUST drop the packet.
> \end{itemize}
>
> \paragraph{Offloads State Configuration}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Offloads State Configuration}
> --
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread* [virtio-dev] Re: [PATCH v4] virtio-net: support reset queue
2022-04-24 6:53 ` Michael S. Tsirkin
@ 2022-04-24 7:57 ` Xuan Zhuo
0 siblings, 0 replies; 5+ messages in thread
From: Xuan Zhuo @ 2022-04-24 7:57 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: virtio-dev, jasowang
On Sun, 24 Apr 2022 02:53:46 -0400, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Tue, Feb 22, 2022 at 02:52:41PM +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>
>
> Suggest creating a github issue documenting that it is not defined
> what the behaviour is, so we rememeber to list this as a known issue
> in 1.2.
OK.
>
>
> > ---
> > content.tex | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/content.tex b/content.tex
> > index c6f116c..45751f4 100644
> > --- a/content.tex
> > +++ b/content.tex
> > @@ -4337,6 +4337,10 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> > \field{virtqueue_pairs} once it has placed the
> > VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command in a used buffer.
> >
> > +If the destination receive queue is in reset state(See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}),
>
> Should this be "a reset state"? Also, I do not see any definition of "reset state" in
> the linked chapter. That chapter should really be cleaned up btw.
Oh, I will try to clean that.
>
> > +the device SHOULD re-select a different random queue.
>
> different from what?
>
> I suspect we want to move this:
>
> When multiqueue is enabled by VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command, the device MUST use automatic receive steering
> based on packet flow. Programming of the receive steering
> classificator is implicit. After the driver transmitted a packet of a
> flow on transmitqX, the device SHOULD cause incoming packets for that flow to
> be steered to receiveqX. For uni-directional protocols, or where
> no packets have been transmitted yet, the device MAY steer a packet
> to a random queue out of the specified receiveq1\ldots receiveqn.
>
>
>
> to a conformance chapter, and be replaced with a general description
> avoiding conformance keyworkds like MUST and SHOULD.
>
>
> Generally, whenever we have conformance keywords out of conformance
> clauses it's a bug and source of confusion at some point.
Agreed, can we do some cleanup for these cases before 1.3.
Thanks.
>
>
> > If all receive queues are
> > +in reset state, the device MUST drop the packet.
> > +
> > \subparagraph{Legacy Interface: Automatic receive steering in multiqueue mode}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode / Legacy Interface: Automatic receive steering in multiqueue mode}
> > When using the legacy interface, transitional devices and drivers
> > MUST format \field{virtqueue_pairs}
> > @@ -4425,6 +4429,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device Types / Network Device / Devi
> > \item Calculate the hash of the packet as defined in \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets / Hash calculation for incoming packets}.
> > \item If the device did not calculate the hash for the specific packet, the device directs the packet to the receiveq specified by \field{unclassified_queue} of virtio_net_rss_config structure (value of 0 corresponds to receiveq1).
> > \item Apply \field{indirection_table_mask} to the calculated hash and use the result as the index in the indirection table to get 0-based number of destination receiveq (value of 0 corresponds to receiveq1).
> > +\item If the destination receive queue is in reset state(See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}), the device MUST drop the packet.
> > \end{itemize}
> >
> > \paragraph{Offloads State Configuration}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Offloads State Configuration}
> > --
> > 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
^ permalink raw reply [flat|nested] 5+ messages in thread