Re: [PATCH v4] virtio-net: support reset queue

["Michael S. Tsirkin" <mst@redhat.com>]

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