From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-comment-return-982-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id EBA17985F78 for ; Tue, 3 Dec 2019 20:25:39 +0000 (UTC) Date: Tue, 3 Dec 2019 15:25:30 -0500 From: "Michael S. Tsirkin" Message-ID: <20191203152148-mutt-send-email-mst@kernel.org> References: <20191203183212.1721642-1-yuri.benditovich@daynix.com> MIME-Version: 1.0 In-Reply-To: <20191203183212.1721642-1-yuri.benditovich@daynix.com> Subject: [virtio-comment] Re: [PATCH] virtio-net: define feature of per-packet RSS hash delivery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline To: Yuri Benditovich Cc: virtio-comment@lists.oasis-open.org List-ID: On Tue, Dec 03, 2019 at 08:32:12PM +0200, Yuri Benditovich wrote: > Fixes: https://github.com/oasis-tcs/virtio-spec/issues/66 > Conditional extending of virtio header structure to deliver > packet's hash and hash type used for calculation. >=20 > Signed-off-by: Yuri Benditovich Functionally this looks mostly good. But we need to change the way it's documented slightly. > --- > content.tex | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) >=20 > diff --git a/content.tex b/content.tex > index 01be7df..44975e4 100644 > --- a/content.tex > +++ b/content.tex > @@ -2811,6 +2811,9 @@ \subsection{Feature bits}\label{sec:Device Types / = Network Device / Feature bits > \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control > channel. > =20 > +\item[VIRTIO_NET_F_HASH_REPORT(58)] Device can report per-packet hash va= lue > + and a type of calculated hash > + > \item[VIRTIO_NET_F_RSS(60)] Device supports RSS (receive-side scaling) > with Toeplitz hash calculation and configurable hash parameters for = receive steering > =20 > @@ -2844,6 +2847,8 @@ \subsubsection{Feature bit requirements}\label{sec:= Device Types / Network Device > \item[VIRTIO_NET_F_CTRL_MAC_ADDR] Requires VIRTIO_NET_F_CTRL_VQ. > \item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or VIRTIO_NE= T_F_HOST_TSO6. > \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ. > +\item[VIRTIO_NET_F_HASH_REPORT] Requires VIRTIO_NET_F_RSS. > + > \end{description} > =20 > \subsubsection{Legacy Interface: Feature bits}\label{sec:Device Types / = Network Device / Feature bits / Legacy Interface: Feature bits} > @@ -3071,6 +3076,8 @@ \subsection{Device Operation}\label{sec:Device Type= s / Network Device / Device O > le16 csum_start; > le16 csum_offset; > le16 num_buffers; > + le32 hash_value; (Only if VIRTIO_NET_F_HASH_REPORT negotiated) > + le16 hash_type; (Only if VIRTIO_NET_F_HASH_REPORT negotiated) > }; > \end{lstlisting} > =20 > @@ -3330,6 +3337,15 @@ \subsubsection{Processing of Incoming Packets}\lab= el{sec:Device Types / Network > set: if so, device has validated the packet checksum. > In case of multiple encapsulated protocols, one level of checksums > has been validated. > +\item If VIRTIO_NET_F_HASH_REPORT was negotiated and a device has calcul= ated > + a hash for the packet, \field{hash_value} contains calculated hash val= ue and > + \field{hash_type} contains exact hash type. > + > + If the hash was not calculated, \field{hash_type} contains zero. > + > + For defined hash types and their meaning, see \ref{sec:Device Types / = Network Device / Device configuration layout / RSS}. > + > + For the procedure of hash calculation, see \ref{sec:Device Types / Net= work Device / Device Operation / Control Virtqueue / Receive-side scaling (= RSS) / RSS hash types}. > \end{enumerate} > =20 > Additionally, VIRTIO_NET_F_GUEST_CSUM, TSO4, TSO6, UDP and ECN > @@ -3909,6 +3925,14 @@ \subsubsection{Control Virtqueue}\label{sec:Device= Types / Network Device / Devi > \item Else skip IPv6 extension headers and calculate the hash as defined= above for IPv6 packet without extension headers > \end{itemize} > =20 > +If VIRTIO_NET_F_HASH_REPORT was negotiated, the device reports calculate= d hash information in fields of virtio_net_hdr as follows: > + > +Exact hash type is populated in \field{hash_type} > + > +Hash value is populated in \field{hash_value} > + > +If, due to any reason, the device did not calculate the hash, it sets \f= ield{hash_type} to zero. > + > \drivernormative{\subparagraph}{Setting RSS parameters}{Device Types / N= etwork Device / Device Operation / Control Virtqueue / Receive-side scaling= (RSS) } > =20 > A driver MUST NOT send the VIRTIO_NET_CTRL_MQ_RSS_CONFIG command if the = feature VIRTIO_NET_F_RSS has not been negotiated. This is understandably a minimal change, but imho messes things up: hash calculation is no longer part of RSS so really should be moved from out of there. So we'd have a chapter for hash calculation, defining hash types etc. Then both RSS and the new chapter refer to that. Also, I am guessing supported hash types should be valid in config space with the new feature - isn't that right? > --=20 > 2.17.2 This publicly archived list offers a means to provide input to the=0D OASIS Virtual I/O Device (VIRTIO) TC.=0D =0D In order to verify user consent to the Feedback License terms and=0D to minimize spam in the list archive, subscription is required=0D before posting.=0D =0D Subscribe: virtio-comment-subscribe@lists.oasis-open.org=0D Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org=0D List help: virtio-comment-help@lists.oasis-open.org=0D List archive: https://lists.oasis-open.org/archives/virtio-comment/=0D Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf= =0D List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lis= ts=0D Committee: https://www.oasis-open.org/committees/virtio/=0D Join OASIS: https://www.oasis-open.org/join/