From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-comment-return-1070-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 0C99B985EAC for ; Wed, 19 Feb 2020 14:49:45 +0000 (UTC) Date: Wed, 19 Feb 2020 09:49:37 -0500 (EST) From: Yuri Benditovich Message-ID: <1785864968.7261240.1582123777151.JavaMail.zimbra@redhat.com> In-Reply-To: <20200219092917-mutt-send-email-mst@kernel.org> References: <20200219075337.23191-1-yuri.benditovich@daynix.com> <20200219075337.23191-2-yuri.benditovich@daynix.com> <20200219040122-mutt-send-email-mst@kernel.org> <1841911156.7222325.1582110433680.JavaMail.zimbra@redhat.com> <20200219092917-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Subject: Re: [virtio-comment] Re: [PATCH v4 1/1] virtio-net: Define per-packet hash reporting feature Content-Type: multipart/alternative; boundary="----=_Part_7261239_1035068924.1582123777149" To: "Michael S. Tsirkin" Cc: Yuri Benditovich , virtio-comment@lists.oasis-open.org List-ID: ------=_Part_7261239_1035068924.1582123777149 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Michael S. Tsirkin" > To: "Yuri Benditovich" > Cc: "Yuri Benditovich" , > virtio-comment@lists.oasis-open.org > Sent: Wednesday, February 19, 2020 4:35:49 PM > Subject: Re: [virtio-comment] Re: [PATCH v4 1/1] virtio-net: Define > per-packet hash reporting feature > On Wed, Feb 19, 2020 at 06:07:13AM -0500, Yuri Benditovich wrote: > > > > > > =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81 > > > > From: "Michael S. Tsirkin" > > To: "Yuri Benditovich" > > Cc: virtio-comment@lists.oasis-open.org > > Sent: Wednesday, February 19, 2020 11:12:40 AM > > Subject: [virtio-comment] Re: [PATCH v4 1/1] virtio-net: Define per-pac= ket > > hash reporting feature > > > > On Wed, Feb 19, 2020 at 09:53:37AM +0200, Yuri Benditovich wrote: > > > Fixes: https://github.com/oasis-tcs/virtio-spec/issues/66 > > > Define respective feature bit for virtio-net. > > > Extend packet layout to populate hash value and type. > > > Move the definition of IP/TCP/UDP header fields to > > > calculate the hash out of RSS section to common network > > > device section. > > > > > > Signed-off-by: Yuri Benditovich > > > --- > > > content.tex | 347 ++++++++++++++++++++++++++++++++++-----------------= - > > > 1 file changed, 229 insertions(+), 118 deletions(-) > > > > > > diff --git a/content.tex b/content.tex > > > index b91a132..d7d4e42 100644 > > > --- a/content.tex > > > +++ b/content.tex > > > @@ -2895,6 +2895,9 @@ \subsection{Feature bits}\label{sec:Device Type= s / > > Network Device / Feature bits > > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control > > > channel. > > > > > > +\item[VIRTIO_NET_F_HASH_REPORT(57)] Device can report per-packet has= h > > > + value and a type of calculated hash. > > > + > > > \item[VIRTIO_NET_F_GUEST_HDRLEN(59)] Driver can provide the exact \fi= eld > > {hdr_len} > > > value. Device benefits from knowing the exact header length. > > > > > > @@ -2995,35 +2998,17 @@ \subsection{Device configuration layout}\labe= l > > {sec:Device Types / Network Device > > > le32 supported_hash_types; > > > }; > > > \end{lstlisting} > > > -\label{sec:Device Types / Network Device / Device configuration layo= ut / > > RSS} > > > -Three following fields, \field{rss_max_key_size}, \field > > {rss_max_indirection_table_length} > > > -and \field{supported_hash_types} only exist if VIRTIO_NET_F_RSS is s= et. > > > +The following field, \field{rss_max_key_size} only exist if > > VIRTIO_NET_F_RSS or VIRTIO_NET_F_HASH_REPORT is set. > > > +It specifies the maximal supported length of RSS key in bytes. > > > > > > -Field \field{rss_max_key_size} specifies the maximal supported lengt= h of > > RSS key in bytes. > > > +The following field, \field{rss_max_indirection_table_length} only e= xist > > if VIRTIO_NET_F_RSS is set. > > > +It specifies the maximal number of 16-bit entries in RSS indirection > > table. > > > > > > -Field \field{rss_max_indirection_table_length} specifies the maximal > > number of 16-bit entries in RSS indirection table. > > > +The next field, \field{supported_hash_types} exists only if the devi= ce > > supports hash calculation, > > > +i.e. if VIRTIO_NET_F_RSS or VIRTIO_NET_F_HASH_REPORT is set. > > > > > > -Field \field{supported_hash_types} contains the bitmask of supported= RSS > > hash types. > > > - > > > -Hash types applicable for IPv4 packets: > > > -\begin{lstlisting} > > > -#define VIRTIO_NET_RSS_HASH_TYPE_IPv4 (1 << 0) > > > -#define VIRTIO_NET_RSS_HASH_TYPE_TCPv4 (1 << 1) > > > -#define VIRTIO_NET_RSS_HASH_TYPE_UDPv4 (1 << 2) > > > -\end{lstlisting} > > > -Hash types applicable for IPv6 packets without extension headers > > > -\begin{lstlisting} > > > -#define VIRTIO_NET_RSS_HASH_TYPE_IPv6 (1 << 3) > > > -#define VIRTIO_NET_RSS_HASH_TYPE_TCPv6 (1 << 4) > > > -#define VIRTIO_NET_RSS_HASH_TYPE_UDPv6 (1 << 5) > > > -\end{lstlisting} > > > -Hash types applicable for IPv6 packets with extension headers > > > -\begin{lstlisting} > > > -#define VIRTIO_NET_RSS_HASH_TYPE_IP_EX (1 << 6) > > > -#define VIRTIO_NET_RSS_HASH_TYPE_TCP_EX (1 << 7) > > > -#define VIRTIO_NET_RSS_HASH_TYPE_UDP_EX (1 << 8) > > > -\end{lstlisting} > > > -For the exact meaning of VIRTIO_NET_RSS_HASH_TYPE_ flags see \ref > > {sec:Device Types / Network Device / Device Operation / Control Virtque= ue / > > Receive-side scaling (RSS) / RSS hash types}. > > > +Field \field{supported_hash_types} contains the bitmask of supported > > hash types. > > > +See \ref{sec:Device Types / Network Device / Device Operation / > > Processing of Incoming Packets / Hash calculation for incoming packets = / > > Supported/enabled hash types} for details of supported hash types. > > > > > > \devicenormative{\subsubsection}{Device configuration layout}{Device > > Types / Network Device / Device configuration layout} > > > > > > @@ -3048,7 +3033,7 @@ \subsection{Device configuration layout}\label > > {sec:Device Types / Network Device > > > negotiated. > > > > > > The device MUST set \field{rss_max_key_size} to at least 40, if it > > offers > > > -VIRTIO_NET_F_RSS. > > > +VIRTIO_NET_F_RSS or VIRTIO_NET_F_HASH_REPORT. > > > > > > The device MUST set \field{rss_max_indirection_table_length} to at le= ast > > 128, if it offers > > > VIRTIO_NET_F_RSS. > > > @@ -3195,6 +3180,8 @@ \subsection{Device Operation}\label{sec:Device > > Types / 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) > > > }; > > > > Just noticed this - it's a bit problematic as it might force > > compilers to add 2 bytes of padding at the end. Let's add extra 2 bytes > > of padding explicitly? > > > > OK, no problem > > > > > > > > > > > \end{lstlisting} > > > > > > @@ -3517,6 +3504,12 @@ \subsubsection{Processing of Incoming Packets}= \ > > label{sec:Device Types / Network > > > > > > \end{enumerate} > > > > > > +If applicable, the device calculates per-packet hash for incoming > > packets as > > > +defined in \ref{sec:Device Types / Network Device / Device Operation= / > > Processing of Incoming Packets / Hash calculation for incoming packets}= . > > > + > > > +If applicable, the device reports hash information for incoming pack= ets > > as > > > +defined in \ref{sec:Device Types / Network Device / Device Operation= / > > Processing of Incoming Packets / Hash reporting for incoming packets}. > > > + > > > \devicenormative{\paragraph}{Processing of Incoming Packets}{Device > > Types / Network Device / Device Operation / Processing of Incoming Pack= ets} > > > \label{devicenormative:Device Types / Network Device / Device Operati= on > > / Processing of Packets}%old label for latexdiff > > > > > > @@ -3619,6 +3612,181 @@ \subsubsection{Processing of Incoming Packets= }\ > > label{sec:Device Types / Network > > > If neither VIRTIO_NET_HDR_F_NEEDS_CSUM nor > > > VIRTIO_NET_HDR_F_DATA_VALID is set, the driver MUST NOT > > > rely on the packet checksum being correct. > > > + > > > +\paragraph{Hash calculation for incoming packets} > > > +\label{sec:Device Types / Network Device / Device Operation / Proces= sing > > of Incoming Packets / Hash calculation for incoming packets} > > > + > > > +A device attempts to calculate a per-packet hash in the following ca= ses: > > > +\begin{itemize} > > > +\item The feature VIRTIO_NET_F_RSS was negotiated. The device uses t= he > > hash to determine the receive virtqueue to place incoming packets. > > > +\item The feature VIRTIO_NET_F_HASH_REPORT was negotiated. The devic= e > > reports the hash value and the hash type with the packet. > > > +\end{itemize} > > > + > > > +If the feature VIRTIO_NET_F_RSS was negotiated: > > > +\begin{itemize} > > > +\item The device uses \field{hash_types} of the virtio_net_rss_confi= g > > structure as 'Enabled hash types' bitmask. > > > +\item The device uses a key as defined in \field{hash_key_data} and = \ > > field{hash_key_length} of the virtio_net_rss_config structure (see > > > +\ref{sec:Device Types / Network Device / Device Operation / Control > > Virtqueue / Receive-side scaling (RSS) / Setting RSS parameters}). > > > +\end{itemize} > > > + > > > +If the feature VIRTIO_NET_F_RSS was not negotiated: > > > +\begin{itemize} > > > +\item The device uses \field{hash_types} of the virtio_net_hash_conf= ig > > structure as 'Enabled hash types' bitmask. > > > +\item The device uses a key as defined in \field{hash_key_data} and = \ > > field{hash_key_length} of the virtio_net_hash_config structure (see > > > +\ref{sec:Device Types / Network Device / Device Operation / Control > > Virtqueue / Automatic receive steering in multiqueue mode / Hash > > calculation}). > > > +\end{itemize} > > > + > > > +Note that if the device offers VIRTIO_NET_F_HASH_REPORT, even if it > > supports only one pair of virtqueues, it MUST support > > > +at least one of commands of VIRTIO_NET_CTRL_MQ class to configure > > reported hash parameters: > > > +\begin{itemize} > > > +\item If the device offers VIRTIO_NET_F_RSS, it MUST support > > VIRTIO_NET_CTRL_MQ_RSS_CONFIG command per > > > + \ref{sec:Device Types / Network Device / Device Operation / Control > > Virtqueue / Receive-side scaling (RSS) / Setting RSS parameters}. > > > +\item Otherwise the device MUST support VIRTIO_NET_CTRL_MQ_HASH_CONF= IG > > command per > > > + \ref{sec:Device Types / Network Device / Device Operation / Control > > Virtqueue / Automatic receive steering in multiqueue mode / Hash > > calculation}. > > > +\end{itemize} > > > + > > > +\subparagraph{Supported/enabled hash types} > > > +\label{sec:Device Types / Network Device / Device Operation / Proces= sing > > of Incoming Packets / Hash calculation for incoming packets / Supported= / > > enabled hash types} > > > +Hash types applicable for IPv4 packets: > > > +\begin{lstlisting} > > > +#define VIRTIO_NET_HASH_TYPE_IPv4 (1 << 0) > > > +#define VIRTIO_NET_HASH_TYPE_TCPv4 (1 << 1) > > > +#define VIRTIO_NET_HASH_TYPE_UDPv4 (1 << 2) > > > +\end{lstlisting} > > > +Hash types applicable for IPv6 packets without extension headers > > > +\begin{lstlisting} > > > +#define VIRTIO_NET_HASH_TYPE_IPv6 (1 << 3) > > > +#define VIRTIO_NET_HASH_TYPE_TCPv6 (1 << 4) > > > +#define VIRTIO_NET_HASH_TYPE_UDPv6 (1 << 5) > > > +\end{lstlisting} > > > +Hash types applicable for IPv6 packets with extension headers > > > +\begin{lstlisting} > > > +#define VIRTIO_NET_HASH_TYPE_IP_EX (1 << 6) > > > +#define VIRTIO_NET_HASH_TYPE_TCP_EX (1 << 7) > > > +#define VIRTIO_NET_HASH_TYPE_UDP_EX (1 << 8) > > > +\end{lstlisting} > > > + > > > +\subparagraph{IPv4 packets} > > > +\label{sec:Device Types / Network Device / Device Operation / Proces= sing > > of Incoming Packets / Hash calculation for incoming packets / IPv4 pack= ets} > > > +The device calculates the hash on IPv4 packets according to 'Enabled > > hash types' bitmask as follows: > > > +\begin{itemize} > > > +\item If VIRTIO_NET_HASH_TYPE_TCPv4 is set and the packet has > > > +a TCP header, the hash is calculated over the following fields: > > > +\begin{itemize} > > > +\item Source IP address > > > +\item Destination IP address > > > +\item Source TCP port > > > +\item Destination TCP port > > > +\end{itemize} > > > +\item Else if VIRTIO_NET_HASH_TYPE_UDPv4 is set and the > > > +packet has a UDP header, the hash is calculated over the following > > fields: > > > +\begin{itemize} > > > +\item Source IP address > > > +\item Destination IP address > > > +\item Source UDP port > > > +\item Destination UDP port > > > +\end{itemize} > > > +\item Else if VIRTIO_NET_HASH_TYPE_IPv4 is set, the hash is > > > +calculated over the following fields: > > > +\begin{itemize} > > > +\item Source IP address > > > +\item Destination IP address > > > +\end{itemize} > > > +\item Else the device does not calculate the hash > > > +\end{itemize} > > > + > > > +\subparagraph{IPv6 packets without extension header} > > > +\label{sec:Device Types / Network Device / Device Operation / Proces= sing > > of Incoming Packets / Hash calculation for incoming packets / IPv6 pack= ets > > without extension header} > > > +The device calculates the hash on IPv6 packets without extension > > > +headers according to 'Enabled hash types' bitmask as follows: > > > +\begin{itemize} > > > +\item If VIRTIO_NET_HASH_TYPE_TCPv6 is set and the packet has > > > +a TCPv6 header, the hash is calculated over the following fields: > > > +\begin{itemize} > > > +\item Source IPv6 address > > > +\item Destination IPv6 address > > > +\item Source TCP port > > > +\item Destination TCP port > > > +\end{itemize} > > > +\item Else if VIRTIO_NET_HASH_TYPE_UDPv6 is set and the > > > +packet has a UDPv6 header, the hash is calculated over the following > > fields: > > > +\begin{itemize} > > > +\item Source IPv6 address > > > +\item Destination IPv6 address > > > +\item Source UDP port > > > +\item Destination UDP port > > > +\end{itemize} > > > +\item Else if VIRTIO_NET_HASH_TYPE_IPv6 is set, the hash is > > > +calculated over the following fields: > > > +\begin{itemize} > > > +\item Source IPv6 address > > > +\item Destination IPv6 address > > > +\end{itemize} > > > +\item Else the device does not calculate the hash > > > +\end{itemize} > > > + > > > +\subparagraph{IPv6 packets with extension header} > > > +\label{sec:Device Types / Network Device / Device Operation / Proces= sing > > of Incoming Packets / Hash calculation for incoming packets / IPv6 pack= ets > > with extension header} > > > +The device calculates the hash on IPv6 packets with extension > > > +headers according to 'Enabled hash types' bitmask as follows: > > > +\begin{itemize} > > > +\item If VIRTIO_NET_HASH_TYPE_TCP_EX is set and the packet > > > +has a TCPv6 header, the hash is calculated over the following fields= : > > > +\begin{itemize} > > > +\item Home address from the home address option in the IPv6 destinat= ion > > options header. If the extension header is not present, use the Source = IPv6 > > address. > > > +\item IPv6 address that is contained in the Routing-Header-Type-2 fr= om > > the associated extension header. If the extension header is not present= , > > use the Destination IPv6 address. > > > +\item Source TCP port > > > +\item Destination TCP port > > > +\end{itemize} > > > +\item Else if VIRTIO_NET_HASH_TYPE_UDP_EX is set and the > > > +packet has a UDPv6 header, the hash is calculated over the following > > fields: > > > +\begin{itemize} > > > +\item Home address from the home address option in the IPv6 destinat= ion > > options header. If the extension header is not present, use the Source = IPv6 > > address. > > > +\item IPv6 address that is contained in the Routing-Header-Type-2 fr= om > > the associated extension header. If the extension header is not present= , > > use the Destination IPv6 address. > > > +\item Source UDP port > > > +\item Destination UDP port > > > +\end{itemize} > > > +\item Else if VIRTIO_NET_HASH_TYPE_IP_EX is set, the hash is > > > +calculated over the following fields: > > > +\begin{itemize} > > > +\item Home address from the home address option in the IPv6 destinat= ion > > options header. If the extension header is not present, use the Source = IPv6 > > address. > > > +\item IPv6 address that is contained in the Routing-Header-Type-2 fr= om > > the associated extension header. If the extension header is not present= , > > use the Destination IPv6 address. > > > +\end{itemize} > > > +\item Else skip IPv6 extension headers and calculate the hash as > > > +defined for an IPv6 packet without extension headers > > > +(see \ref{sec:Device Types / Network Device / Device Operation / > > Processing of Incoming Packets / Hash calculation for incoming packets = / > > IPv6 packets without extension header}). > > > +\end{itemize} > > > + > > > +\paragraph{Hash reporting for incoming packets} > > > +\label{sec:Device Types / Network Device / Device Operation / Proces= sing > > of Incoming Packets / Hash reporting for incoming packets} > > > + > > > +If VIRTIO_NET_F_HASH_REPORT was negotiated and > > > + the device has calculated the hash for the packet, the device fills= \ > > field{hash_type} with the type of calculated hash > > > +and \field{hash_value} with the value of calculated hash. > > > + > > > +If VIRTIO_NET_F_HASH_REPORT was negotiated but due to any reason the > > > +hash was not calculated, the device sets \field{hash_type} to > > VIRTIO_NET_HASH_REPORT_NONE. > > > + > > > +Possible values that the device can report in \field{hash_type} are > > defined below. > > > +They correspond to supported hash types defined in > > > +\ref{sec:Device Types / Network Device / Device Operation / Processi= ng > > of Incoming Packets / Hash calculation for incoming packets / Supported= / > > enabled hash types} > > > +as follows: > > > + > > > +VIRTIO_NET_HASH_TYPE_XXX =3D 1 << (VIRTIO_NET_HASH_REPORT_XXX - 1) > > > > > > So hash_type is the HASH_REPORT value then? That's quite confusing. > > Let's rename to hash_report? > > > > No problem to rename anything, but I'd like to do it one time. > > Currently meaningful hash report values are (1..9), 0 for none > > They correspond to bitmask of 9 bits for enabled/supported. > > It was possible to use the same definitions for enable/support/report > > but then reported kind of hash should be 4 bytes. > > As you anyway suggests padding at the end of the packet, we can do that= , > > i.e. add (32 bit hash + 32 bit type) > We can but it seems like a waste, does it not? padding can be used for > something later ... > > Or if we stay with the values as they are now: > > values 0..9 - VIRTIO_NET_WHAT? > I thought that's VIRTIO_NET_HASH_REPORT_XXX OK, this is exactly what is defined=20 > > bits from 0 to 8 - VIRTIO_NET_WHAT? > and this one VIRTIO_NET_HASH_TYPE_XXX? OK, this is also exactly what is defined=20 > Generally what you did here is a bit unusual. Mostly we just define > bit numbers > #define VIRTIO_SCSI_F_INOUT 0 > #define VIRTIO_SCSI_F_HOTPLUG 1 > #define VIRTIO_SCSI_F_CHANGE 2 > #define VIRTIO_SCSI_F_T10_PI 3 Value 0 of hash_report is "no hash calculated" and it does not=20 participate in support/enable mask. I did not want to=20 use value other than zero for "no hash".=20 So you want bit 0 to be reserved (not used) in enable/support mask=20 and then to have all the VIRTIO_NET_HASH_TYPE_XXX to be=20 exactly 1 << VIRTIO_NET_HASH_REPORT_XXX? Just say...=20 > and just say that bit numbers are from this table, with bit > 0 corresponding to the value 0, bit 1 to value 1 etc. > maybe that would have been easier on the eyes - I didn't try, > I'm not even sure. > But what you have is correct enough, we can always try to > improve the wording later. > > > > > > > + > > > +\begin{lstlisting} > > > +#define VIRTIO_NET_HASH_REPORT_NONE 0 > > > +#define VIRTIO_NET_HASH_REPORT_IPv4 1 > > > +#define VIRTIO_NET_HASH_REPORT_TCPv4 2 > > > +#define VIRTIO_NET_HASH_REPORT_UDPv4 3 > > > +#define VIRTIO_NET_HASH_REPORT_IPv6 4 > > > +#define VIRTIO_NET_HASH_REPORT_TCPv6 5 > > > +#define VIRTIO_NET_HASH_REPORT_UDPv6 6 > > > +#define VIRTIO_NET_HASH_REPORT_IPv6_EX 7 > > > +#define VIRTIO_NET_HASH_REPORT_TCPv6_EX 8 > > > +#define VIRTIO_NET_HASH_REPORT_UDPv6_EX 9 > > > +\end{lstlisting} > > > + > > > \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 > > > @@ -3896,6 +4064,7 @@ \subsubsection{Control Virtqueue}\label{sec:Dev= ice > > Types / Network Device / Devi > > > #define VIRTIO_NET_CTRL_MQ 4 > > > #define VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET 0 (for automatic receive > > steering) > > > #define VIRTIO_NET_CTRL_MQ_RSS_CONFIG 1 (for configurable > > receive steering) > > > + #define VIRTIO_NET_CTRL_MQ_HASH_CONFIG 2 (for configurable hash > > calculation) > > > \end{lstlisting} > > > > > > If more than one multiqueue mode is negotiated, the resulting device > > configuration is defined by the last command sent by the driver. > > > @@ -3961,10 +4130,37 @@ \subsubsection{Control Virtqueue}\label > > {sec:Device Types / Network Device / Devi > > > according to the native endian of the guest rather than > > > (necessarily when not using the legacy interface) little-endian. > > > > > > +\subparagraph{Hash calculation}\label{sec:Device Types / Network Dev= ice > > / Device Operation / Control Virtqueue / Automatic receive steering in > > multiqueue mode / Hash calculation} > > > +If VIRTIO_NET_F_HASH_REPORT was negotiated and the device uses autom= atic > > receive steering, > > > +the device MUST support a command to configure hash calculation > > parameters. > > > + > > > +The driver provides parameters for hash calculation as follows: > > > + > > > +\field{class} VIRTIO_NET_CTRL_MQ, \field{command} > > VIRTIO_NET_CTRL_MQ_HASH_CONFIG. > > > + > > > +The \field{command-specific-data} has following format: > > > +\begin{lstlisting} > > > +struct virtio_net_hash_config { > > > + le32 hash_types; > > > + le16 reserved[4]; > > > + u8 hash_key_length; > > > + u8 hash_key_data[hash_key_length]; > > > +}; > > > +\end{lstlisting} > > > +Field \field{hash_types} contains a bitmask of allowed hash types as > > > +defined in > > > +\ref{sec:Device Types / Network Device / Device Operation / Processi= ng > > of Incoming Packets / Hash calculation for incoming packets / Supported= / > > enabled hash types}. > > > +Initially the device has all hash types disabled and reports only > > VIRTIO_NET_HASH_REPORT_NONE. > > > + > > > +Field \field{reserved} MUST contain zeroes. It is defined to make th= e > > structure to match the layout of virtio_net_rss_config structure, > > > +defined in \ref{sec:Device Types / Network Device / Device Operation= / > > Control Virtqueue / Receive-side scaling (RSS)}. > > > + > > > +Fields \field{hash_key_length} and \field{hash_key_data} define the = key > > to be used in hash calculation. > > > + > > > \paragraph{Receive-side scaling (RSS)}\label{sec:Device Types / Netwo= rk > > Device / Device Operation / Control Virtqueue / Receive-side scaling (R= SS)} > > > A device offers the feature VIRTIO_NET_F_RSS if it supports RSS recei= ve > > steering with Toeplitz hash calculation and configurable parameters. > > > > > > -A driver queries RSS capabilities of the device by reading device > > configuration as defined in \ref{sec:Device Types / Network Device / De= vice > > configuration layout / RSS} > > > +A driver queries RSS capabilities of the device by reading device > > configuration as defined in \ref{sec:Device Types / Network Device / De= vice > > configuration layout} > > > > > > \subparagraph{Setting RSS parameters}\label{sec:Device Types / Networ= k > > Device / Device Operation / Control Virtqueue / Receive-side scaling (R= SS) > > / Setting RSS parameters} > > > > > > @@ -3981,7 +4177,8 @@ \subsubsection{Control Virtqueue}\label{sec:Dev= ice > > Types / Network Device / Devi > > > }; > > > \end{lstlisting} > > > Field \field{hash_types} contains a bitmask of allowed hash types as > > > -defined in \ref{sec:Device Types / Network Device / Device Operation= / > > Control Virtqueue / Receive-side scaling (RSS) / RSS hash types}. > > > +defined in > > > +\ref{sec:Device Types / Network Device / Device Operation / Processi= ng > > of Incoming Packets / Hash calculation for incoming packets / Supported= / > > enabled hash types}. > > > > > > Field \field{indirection_table_mask} is a mask to be applied to > > > the calculated hash to produce an index in the > > > @@ -3995,93 +4192,7 @@ \subsubsection{Control Virtqueue}\label{sec:De= vice > > Types / Network Device / Devi > > > > > > A driver sets \field{max_tx_vq} to inform a device how many transmit > > virtqueues it may use (transmitq1\ldots transmitq \field{max_tx_vq}). > > > > > > -\subparagraph{RSS hash types}\label{sec:Device Types / Network Devic= e / > > Device Operation / Control Virtqueue / Receive-side scaling (RSS) / RSS > > hash types} > > > - > > > -The device calculates the hash on IPv4 packets according to the > > > -field \field{hash_types} of the virtio_net_rss_config structure as > > follows: > > > -\begin{itemize} > > > -\item If VIRTIO_NET_RSS_HASH_TYPE_TCPv4 is set and the packet has > > > -a TCP header, the hash is calculated over the following fields: > > > -\begin{itemize} > > > -\item Source IP address > > > -\item Destination IP address > > > -\item Source TCP port > > > -\item Destination TCP port > > > -\end{itemize} > > > -\item Else if VIRTIO_NET_RSS_HASH_TYPE_UDPv4 is set and the > > > -packet has a UDP header, the hash is calculated over the following > > fields: > > > -\begin{itemize} > > > -\item Source IP address > > > -\item Destination IP address > > > -\item Source UDP port > > > -\item Destination UDP port > > > -\end{itemize} > > > -\item Else if VIRTIO_NET_RSS_HASH_TYPE_IPv4 is set, the hash is > > > -calculated over the following fields: > > > -\begin{itemize} > > > -\item Source IP address > > > -\item Destination IP address > > > -\end{itemize} > > > -\item Else the device does not calculate the hash > > > -\end{itemize} > > > - > > > -\label{itm:Device Types / Network Device / Device Operation / Contro= l > > Virtqueue / Receive-side scaling (RSS) / RSS hash types/hash on IPv6 > > packets without extension headers} > > > -The device calculates the hash on IPv6 packets without extension > > > -headers according to the field \field{hash_types} of the > > virtio_net_rss_config structure as follows: > > > -\begin{itemize} > > > -\item If VIRTIO_NET_RSS_HASH_TYPE_TCPv6 is set and the packet has > > > -a TCPv6 header, the hash is calculated over the following fields: > > > -\begin{itemize} > > > -\item Source IPv6 address > > > -\item Destination IPv6 address > > > -\item Source TCP port > > > -\item Destination TCP port > > > -\end{itemize} > > > -\item Else if VIRTIO_NET_RSS_HASH_TYPE_UDPv6 is set and the > > > -packet has a UDPv6 header, the hash is calculated over the following > > fields: > > > -\begin{itemize} > > > -\item Source IPv6 address > > > -\item Destination IPv6 address > > > -\item Source UDP port > > > -\item Destination UDP port > > > -\end{itemize} > > > -\item Else if VIRTIO_NET_RSS_HASH_TYPE_IPv6 is set, the hash is > > > -calculated over the following fields: > > > -\begin{itemize} > > > -\item Source IPv6 address > > > -\item Destination IPv6 address > > > -\end{itemize} > > > -\item Else the device does not calculate the hash > > > -\end{itemize} > > > - > > > -The device calculates the hash on IPv6 packets with extension > > > -headers according to the field \field{hash_types} of the > > virtio_net_rss_config structure as follows: > > > -\begin{itemize} > > > -\item If VIRTIO_NET_RSS_HASH_TYPE_TCP_EX is set and the packet > > > -has a TCPv6 header, the hash is calculated over the following fields= : > > > -\begin{itemize} > > > -\item Home address from the home address option in the IPv6 destinat= ion > > options header. If the extension header is not present, use the Source = IPv6 > > address. > > > -\item IPv6 address that is contained in the Routing-Header-Type-2 fr= om > > the associated extension header. If the extension header is not present= , > > use the Destination IPv6 address. > > > -\item Source TCP port > > > -\item Destination TCP port > > > -\end{itemize} > > > -\item Else if VIRTIO_NET_RSS_HASH_TYPE_UDP_EX is set and the > > > -packet has a UDPv6 header, the hash is calculated over the following > > fields: > > > -\begin{itemize} > > > -\item Home address from the home address option in the IPv6 destinat= ion > > options header. If the extension header is not present, use the Source = IPv6 > > address. > > > -\item IPv6 address that is contained in the Routing-Header-Type-2 fr= om > > the associated extension header. If the extension header is not present= , > > use the Destination IPv6 address. > > > -\item Source UDP port > > > -\item Destination UDP port > > > -\end{itemize} > > > -\item Else if VIRTIO_NET_RSS_HASH_TYPE_IP_EX is set, the hash is > > > -calculated over the following fields: > > > -\begin{itemize} > > > -\item Home address from the home address option in the IPv6 destinat= ion > > options header. If the extension header is not present, use the Source = IPv6 > > address. > > > -\item IPv6 address that is contained in the Routing-Header-Type-2 fr= om > > the associated extension header. If the extension header is not present= , > > use the Destination IPv6 address. > > > -\end{itemize} > > > -\item Else skip IPv6 extension headers and calculate the hash as > > > -defined for an IPv6 packet without extension headers (see \ref > > {itm:Device Types / Network Device / Device Operation / Control Virtque= ue / > > Receive-side scaling (RSS) / RSS hash types/hash on IPv6 packets withou= t > > extension headers}). > > > -\end{itemize} > > > +Fields \field{hash_key_length} and \field{hash_key_data} define the = key > > to be used in hash calculation. > > > > > > \drivernormative{\subparagraph}{Setting RSS parameters}{Device Types = / > > Network Device / Device Operation / Control Virtqueue / Receive-side > > scaling (RSS) } > > > > > > @@ -4093,12 +4204,12 @@ \subsubsection{Control Virtqueue}\label > > {sec:Device Types / Network Device / Devi > > > > > > A driver MUST use \field{indirection_table_mask} values that are less > > than \field{rss_max_indirection_table_length} reported by a device. > > > > > > -A driver MUST NOT set any VIRTIO_NET_RSS_HASH_TYPE_ flags that are n= ot > > supported by a device. > > > +A driver MUST NOT set any VIRTIO_NET_HASH_TYPE_ flags that are not > > supported by a device. > > > > > > \devicenormative{\subparagraph}{RSS processing}{Device Types / Networ= k > > Device / Device Operation / Control Virtqueue / Receive-side scaling (R= SS) > > / RSS processing} > > > The device MUST determine the destination queue for a network packet = as > > follows: > > > \begin{itemize} > > > -\item Calculate the hash of the packet as defined in \ref{sec:Device > > Types / Network Device / Device Operation / Control Virtqueue / > > Receive-side scaling (RSS) / RSS hash types} > > > +\item Calculate the hash of the packet as defined in \ref{sec:Device > > Types / Network Device / Device Operation / Processing of Incoming Pack= ets > > / Hash calculation for incoming packets}. > > > \item If the device did not calculate the hash for the specific packe= t, > > 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 num= ber > > of destination receiveq (value of 0 corresponds to receiveq1). > > > \end{itemize} > > > -- > > > 2.17.1 > > > > > > This publicly archived list offers a means to provide input to the > > OASIS Virtual I/O Device (VIRTIO) TC. > > > > In order to verify user consent to the Feedback License terms and > > to minimize spam in the list archive, subscription is required > > before posting. > > > > Subscribe: virtio-comment-subscribe@lists.oasis-open.org > > Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org > > List help: virtio-comment-help@lists.oasis-open.org > > List archive: https://lists.oasis-open.org/archives/virtio-comment/ > > Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.p= df > > List Guidelines: https://www.oasis-open.org/policies-guidelines/ > > mailing-lists > > Committee: https://www.oasis-open.org/committees/virtio/ > > Join OASIS: https://www.oasis-open.org/join/ > > > > > > ------=_Part_7261239_1035068924.1582123777149 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


To: "Y= uri Benditovich" <ybendito@redhat.com>
Cc: "Yuri Benditovic= h" <yuri.benditovich@daynix.com>, virtio-comment@lists.oasis-open.org=
Sent: Wednesday, February 19, 2020 4:35:49 PM
Subject: Re: [virtio-comment] Re: [PATCH v4 1/1] virtio-net: Define per-packet hash= reporting feature

On Wed, Feb 19, 2020 at 06:07:13AM -05= 00, Yuri Benditovich wrote:
>
>
> =E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81
>
>     From: "Michael S. Tsirkin" &= lt;mst@redhat.com>
>     To: "Yuri Benditovich" <yuri= .benditovich@daynix.com>
>     Cc: virtio-comment@lists.= oasis-open.org
>     Sent: Wednesday, February 19, 2020 11:= 12:40 AM
>     Subject: [virtio-comment] Re: [PATCH v4 1/1]= virtio-net: Define per-packet
>     hash reporting feature=
>
>     On Wed, Feb 19, 2020 at 09:53:37AM +0200, Y= uri Benditovich wrote:
>     > Fixes: https://github.com= /oasis-tcs/virtio-spec/issues/66
>     > Define respecti= ve feature bit for virtio-net.
>     > Extend packet lay= out to populate hash value and type.
>     > Move the de= finition of IP/TCP/UDP header fields to
>     > calculat= e the hash out of RSS section to common network
>     > = device section.
>     >
>     > Signe= d-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
> &nbs= p;   > ---
>     >  content.tex | 347 +++++= +++++++++++++++++++++++++++++------------------
>     > =  1 file changed, 229 insertions(+), 118 deletions(-)
>   &n= bsp; >
>     > diff --git a/content.tex b/content.tex=
>     > index b91a132..d7d4e42 100644
>   &n= bsp; > --- a/content.tex
>     > +++ b/content.tex>     > @@ -2895,6 +2895,9 @@ \subsection{Feature bits}\la= bel{sec:Device Types /
>     Network Device / Feature bits<= br>>     >  \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set = MAC address through control
>     >      = channel.
>     >  
>     > +\ite= m[VIRTIO_NET_F_HASH_REPORT(57)] Device can report per-packet hash
> &= nbsp;   > +    value and a type of calculated hash.
&g= t;     > +
>     >  \item[VIRTIO_NET_F= _GUEST_HDRLEN(59)] Driver can provide the exact \field
>    = ; {hdr_len}
>     >      value. Device be= nefits from knowing the exact header length.
>     > &nb= sp;
>     > @@ -2995,35 +2998,17 @@ \subsection{Device c= onfiguration layout}\label
>     {sec:Device Types / Networ= k Device
>     >          le32 = supported_hash_types;
>     >  };
>   &n= bsp; >  \end{lstlisting}
>     > -\label{sec:Dev= ice Types / Network Device / Device configuration layout /
>   &= nbsp; RSS}
>     > -Three following fields, \field{rss_m= ax_key_size}, \field
>     {rss_max_indirection_table_lengt= h}
>     > -and \field{supported_hash_types} only exist = if VIRTIO_NET_F_RSS is set.
>     > +The following field= , \field{rss_max_key_size} only exist if
>     VIRTIO_NET_F= _RSS or VIRTIO_NET_F_HASH_REPORT is set.
>     > +It spe= cifies the maximal supported length of RSS key in bytes.
>   &nb= sp; >  
>     > -Field \field{rss_max_key_size} = specifies the maximal supported length of
>     RSS key in = bytes.
>     > +The following field, \field{rss_max_indi= rection_table_length} only exist
>     if VIRTIO_NET_F_RSS = is set.
>     > +It specifies the maximal number of 16-b= it entries in RSS indirection
>     table.
>   &= nbsp; >  
>     > -Field \field{rss_max_indirect= ion_table_length} specifies the maximal
>     number of 16-= bit entries in RSS indirection table.
>     > +The next = field, \field{supported_hash_types} exists only if the device
>  = ;   supports hash calculation,
>     > +i.e. if VIR= TIO_NET_F_RSS or VIRTIO_NET_F_HASH_REPORT is set.
>     >= ;  
>     > -Field \field{supported_hash_types} con= tains the bitmask of supported RSS
>     hash types.
>= ;     > -
>     > -Hash types applicable fo= r IPv4 packets:
>     > -\begin{lstlisting}
> &nbs= p;   > -#define VIRTIO_NET_RSS_HASH_TYPE_IPv4       =        (1 << 0)
>     > -#defi= ne VIRTIO_NET_RSS_HASH_TYPE_TCPv4            = (1 << 1)
>     > -#define VIRTIO_NET_RSS_HASH_TYP= E_UDPv4             (1 << 2)
> &n= bsp;   > -\end{lstlisting}
>     > -Hash types a= pplicable for IPv6 packets without extension headers
>     = > -\begin{lstlisting}
>     > -#define VIRTIO_NET_RSS= _HASH_TYPE_IPv6              (1 <<= 3)
>     > -#define VIRTIO_NET_RSS_HASH_TYPE_TCPv6 &nbs= p;           (1 << 4)
>     = > -#define VIRTIO_NET_RSS_HASH_TYPE_UDPv6         &n= bsp;   (1 << 5)
>     > -\end{lstlisting}
= >     > -Hash types applicable for IPv6 packets with extens= ion headers
>     > -\begin{lstlisting}
>   &= nbsp; > -#define VIRTIO_NET_RSS_HASH_TYPE_IP_EX       &nb= sp;     (1 << 6)
>     > -#define VIRTIO= _NET_RSS_HASH_TYPE_TCP_EX            (1 <&= lt; 7)
>     > -#define VIRTIO_NET_RSS_HASH_TYPE_UDP_EX =            (1 << 8)
>   &nbs= p; > -\end{lstlisting}
>     > -For the exact meaning= of VIRTIO_NET_RSS_HASH_TYPE_ flags see \ref
>     {sec:Dev= ice Types / Network Device / Device Operation / Control Virtqueue /
>=     Receive-side scaling (RSS) / RSS hash types}.
>  =   > +Field \field{supported_hash_types} contains the bitmask of su= pported
>     hash types.
>     > +See \= ref{sec:Device Types / Network Device / Device Operation /
>   &= nbsp; Processing of Incoming Packets / Hash calculation for incoming packet= s /
>     Supported/enabled hash types} for details of supp= orted hash types.
>     >  
>     &= gt;  \devicenormative{\subsubsection}{Device configuration layout}{Dev= ice
>     Types / Network Device / Device configuration lay= out}
>     >  
>     > @@ -3048,= 7 +3033,7 @@ \subsection{Device configuration layout}\label
>   =   {sec:Device Types / Network Device
>     >  = negotiated.
>     >  
>     > &n= bsp;The device MUST set \field{rss_max_key_size} to at least 40, if it
&= gt;     offers
>     > -VIRTIO_NET_F_RSS.
&= gt;     > +VIRTIO_NET_F_RSS or VIRTIO_NET_F_HASH_REPORT.
&g= t;     >  
>     >  The device MU= ST set \field{rss_max_indirection_table_length} to at least
>   =   128, if it offers
>     >  VIRTIO_NET_F_RSS.=
>     > @@ -3195,6 +3180,8 @@ \subsection{Device Operat= ion}\label{sec:Device
>     Types / Network Device / Device= O
>     >          le16 csum_s= tart;
>     >          le16 csu= m_offset;
>     >          le16= num_buffers;
>     > +        le32 = hash_value; (Only if VIRTIO_NET_F_HASH_REPORT negotiated)
>   &n= bsp; > +        le16 hash_type;  (Only if VIRTI= O_NET_F_HASH_REPORT negotiated)
>     >  };
>=
>     Just noticed this - it's a bit problematic as it mi= ght force
>     compilers to add 2 bytes of padding at the = end. Let's add extra 2 bytes
>     of padding explicitly?>
> OK, no problem
>
>
>
>
> =     >  \end{lstlisting}
>     >  =
>     > @@ -3517,6 +3504,12 @@ \subsubsection{Processin= g of Incoming Packets}\
>     label{sec:Device Types / Netw= ork
>     >  
>     >  \end= {enumerate}
>     >  
>     > +I= f applicable, the device calculates per-packet hash for incoming
> &n= bsp;   packets as
>     > +defined in \ref{sec:Devi= ce Types / Network Device / Device Operation /
>     Proces= sing of Incoming Packets / Hash calculation for incoming packets}.
> =     > +
>     > +If applicable, the device = reports hash information for incoming packets
>     as
&= gt;     > +defined in \ref{sec:Device Types / Network Device /= Device Operation /
>     Processing of Incoming Packets / = Hash reporting for incoming packets}.
>     > +
> =     >  \devicenormative{\paragraph}{Processing of Incomin= g Packets}{Device
>     Types / Network Device / Device Ope= ration / Processing of Incoming Packets}
>     >  \= label{devicenormative:Device Types / Network Device / Device Operation
&= gt;     / Processing of Packets}%old label for latexdiff
> =     >  
>     > @@ -3619,6 +3612,181 @= @ \subsubsection{Processing of Incoming Packets}\
>     lab= el{sec:Device Types / Network
>     >  If neither V= IRTIO_NET_HDR_F_NEEDS_CSUM nor
>     >  VIRTIO_NET_= HDR_F_DATA_VALID is set, the driver MUST NOT
>     > &nb= sp;rely on the packet checksum being correct.
>     > +<= br>>     > +\paragraph{Hash calculation for incoming packet= s}
>     > +\label{sec:Device Types / Network Device / D= evice Operation / Processing
>     of Incoming Packets / Ha= sh calculation for incoming packets}
>     > +
> &= nbsp;   > +A device attempts to calculate a per-packet hash in the = following cases:
>     > +\begin{itemize}
>  =   > +\item The feature VIRTIO_NET_F_RSS was negotiated. The device= uses the
>     hash to determine the receive virtqueue to = place incoming packets.
>     > +\item The feature VIRTI= O_NET_F_HASH_REPORT was negotiated. The device
>     report= s the hash value and the hash type with the packet.
>     &= gt; +\end{itemize}
>     > +
>     > = +If the feature VIRTIO_NET_F_RSS was negotiated:
>     >= +\begin{itemize}
>     > +\item The device uses \field{= hash_types} of the virtio_net_rss_config
>     structure as= 'Enabled hash types' bitmask.
>     > +\item The device= uses a key as defined in \field{hash_key_data} and \
>    = field{hash_key_length} of the virtio_net_rss_config structure (see
>=     > +\ref{sec:Device Types / Network Device / Device Operat= ion / Control
>     Virtqueue / Receive-side scaling (RSS) = / Setting RSS parameters}).
>     > +\end{itemize}
&g= t;     > +
>     > +If the feature VIRTIO_N= ET_F_RSS was not negotiated:
>     > +\begin{itemize}>     > +\item The device uses \field{hash_types} of the v= irtio_net_hash_config
>     structure as 'Enabled hash type= s' bitmask.
>     > +\item The device uses a key as defi= ned in \field{hash_key_data} and \
>     field{hash_key_len= gth} of the virtio_net_hash_config structure (see
>     >= ; +\ref{sec:Device Types / Network Device / Device Operation / Control
&= gt;     Virtqueue / Automatic receive steering in multiqueue mode= / Hash
>     calculation}).
>     > +\e= nd{itemize}
>     > +
>     > +Note t= hat if the device offers VIRTIO_NET_F_HASH_REPORT, even if it
>  = ;   supports only one pair of virtqueues, it MUST support
> &nbs= p;   > +at least one of commands of VIRTIO_NET_CTRL_MQ class to con= figure
>     reported hash parameters:
>    = ; > +\begin{itemize}
>     > +\item If the device off= ers VIRTIO_NET_F_RSS, it MUST support
>     VIRTIO_NET_CTRL= _MQ_RSS_CONFIG command per
>     > + \ref{sec:Device Typ= es / Network Device / Device Operation / Control
>     Virt= queue / Receive-side scaling (RSS) / Setting RSS parameters}.
>  = ;   > +\item Otherwise the device MUST support VIRTIO_NET_CTRL_MQ_H= ASH_CONFIG
>     command per
>     > + \= ref{sec:Device Types / Network Device / Device Operation / Control
> =     Virtqueue / Automatic receive steering in multiqueue mode / H= ash
>     calculation}.
>     > +\end{it= emize}
>     > +
>     > +\subparagra= ph{Supported/enabled hash types}
>     > +\label{sec:Dev= ice Types / Network Device / Device Operation / Processing
>   &= nbsp; of Incoming Packets / Hash calculation for incoming packets / Support= ed/
>     enabled hash types}
>     > +H= ash types applicable for IPv4 packets:
>     > +\begin{l= stlisting}
>     > +#define VIRTIO_NET_HASH_TYPE_IPv4 &n= bsp;            (1 << 0)
>  =   > +#define VIRTIO_NET_HASH_TYPE_TCPv4        = ;     (1 << 1)
>     > +#define VIRTIO_N= ET_HASH_TYPE_UDPv4             (1 << 2)=
>     > +\end{lstlisting}
>     > +H= ash types applicable for IPv6 packets without extension headers
> &nb= sp;   > +\begin{lstlisting}
>     > +#define VIR= TIO_NET_HASH_TYPE_IPv6              (1 &= lt;< 3)
>     > +#define VIRTIO_NET_HASH_TYPE_TCPv6 &= nbsp;           (1 << 4)
>   &nbs= p; > +#define VIRTIO_NET_HASH_TYPE_UDPv6         &nb= sp;   (1 << 5)
>     > +\end{lstlisting}
&= gt;     > +Hash types applicable for IPv6 packets with extensi= on headers
>     > +\begin{lstlisting}
>   &n= bsp; > +#define VIRTIO_NET_HASH_TYPE_IP_EX         &= nbsp;   (1 << 6)
>     > +#define VIRTIO_NET_= HASH_TYPE_TCP_EX            (1 << 7)>     > +#define VIRTIO_NET_HASH_TYPE_UDP_EX    =        (1 << 8)
>     > +\end= {lstlisting}
>     > +
>     > +\subp= aragraph{IPv4 packets}
>     > +\label{sec:Device Types = / Network Device / Device Operation / Processing
>     of I= ncoming Packets / Hash calculation for incoming packets / IPv4 packets}
= >     > +The device calculates the hash on IPv4 packets acc= ording to 'Enabled
>     hash types' bitmask as follows:>     > +\begin{itemize}
>     > +\item= If VIRTIO_NET_HASH_TYPE_TCPv4 is set and the packet has
>   &nb= sp; > +a TCP header, the hash is calculated over the following fields:>     > +\begin{itemize}
>     > +\ite= m Source IP address
>     > +\item Destination IP addres= s
>     > +\item Source TCP port
>     &= gt; +\item Destination TCP port
>     > +\end{itemize}>     > +\item Else if VIRTIO_NET_HASH_TYPE_UDPv4 is set = and the
>     > +packet has a UDP header, the hash is ca= lculated over the following
>     fields:
>   &n= bsp; > +\begin{itemize}
>     > +\item Source IP addr= ess
>     > +\item Destination IP address
>  =   > +\item Source UDP port
>     > +\item Desti= nation UDP port
>     > +\end{itemize}
>   &n= bsp; > +\item Else if VIRTIO_NET_HASH_TYPE_IPv4 is set, the hash is
&= gt;     > +calculated over the following fields:
>  = ;   > +\begin{itemize}
>     > +\item Source IP = address
>     > +\item Destination IP address
> &n= bsp;   > +\end{itemize}
>     > +\item Else the = device does not calculate the hash
>     > +\end{itemize= }
>     > +
>     > +\subparagraph{IP= v6 packets without extension header}
>     > +\label{sec= :Device Types / Network Device / Device Operation / Processing
> &nbs= p;   of Incoming Packets / Hash calculation for incoming packets / IPv= 6 packets
>     without extension header}
>   &n= bsp; > +The device calculates the hash on IPv6 packets without extension=
>     > +headers according to 'Enabled hash types' bitm= ask as follows:
>     > +\begin{itemize}
>   =   > +\item If VIRTIO_NET_HASH_TYPE_TCPv6 is set and the packet has<= br>>     > +a TCPv6 header, the hash is calculated over the= following fields:
>     > +\begin{itemize}
> &nbs= p;   > +\item Source IPv6 address
>     > +\item= Destination IPv6 address
>     > +\item Source TCP port=
>     > +\item Destination TCP port
>   &nbs= p; > +\end{itemize}
>     > +\item Else if VIRTIO_NET= _HASH_TYPE_UDPv6 is set and the
>     > +packet has a UD= Pv6 header, the hash is calculated over the following
>    = fields:
>     > +\begin{itemize}
>     = > +\item Source IPv6 address
>     > +\item Destinati= on IPv6 address
>     > +\item Source UDP port
> &= nbsp;   > +\item Destination UDP port
>     > +\= end{itemize}
>     > +\item Else if VIRTIO_NET_HASH_TYPE= _IPv6 is set, the hash is
>     > +calculated over the f= ollowing fields:
>     > +\begin{itemize}
>  =   > +\item Source IPv6 address
>     > +\item D= estination IPv6 address
>     > +\end{itemize}
> &= nbsp;   > +\item Else the device does not calculate the hash
>= ;     > +\end{itemize}
>     > +
> &n= bsp;   > +\subparagraph{IPv6 packets with extension header}
>=     > +\label{sec:Device Types / Network Device / Device Oper= ation / Processing
>     of Incoming Packets / Hash calcula= tion for incoming packets / IPv6 packets
>     with extensi= on header}
>     > +The device calculates the hash on IP= v6 packets with extension
>     > +headers according to = 'Enabled hash types' bitmask as follows:
>     > +\begin= {itemize}
>     > +\item If VIRTIO_NET_HASH_TYPE_TCP_EX = is set and the packet
>     > +has a TCPv6 header, the h= ash is calculated over the following fields:
>     > +\b= egin{itemize}
>     > +\item Home address from the home = address option in the IPv6 destination
>     options header= . If the extension header is not present, use the Source IPv6
>  = ;   address.
>     > +\item IPv6 address that is co= ntained in the Routing-Header-Type-2 from
>     the associa= ted extension header. If the extension header is not present,
>  = ;   use the Destination IPv6 address.
>     > +\ite= m Source TCP port
>     > +\item Destination TCP port>     > +\end{itemize}
>     > +\item E= lse if VIRTIO_NET_HASH_TYPE_UDP_EX is set and the
>     >= ; +packet has a UDPv6 header, the hash is calculated over the following
= >     fields:
>     > +\begin{itemize}
&= gt;     > +\item Home address from the home address option in = the IPv6 destination
>     options header. If the extension= header is not present, use the Source IPv6
>     address.<= br>>     > +\item IPv6 address that is contained in the Rou= ting-Header-Type-2 from
>     the associated extension head= er. If the extension header is not present,
>     use the D= estination IPv6 address.
>     > +\item Source UDP port<= br>>     > +\item Destination UDP port
>    = ; > +\end{itemize}
>     > +\item Else if VIRTIO_NET_= HASH_TYPE_IP_EX is set, the hash is
>     > +calculated = over the following fields:
>     > +\begin{itemize}
&= gt;     > +\item Home address from the home address option in = the IPv6 destination
>     options header. If the extension= header is not present, use the Source IPv6
>     address.<= br>>     > +\item IPv6 address that is contained in the Rou= ting-Header-Type-2 from
>     the associated extension head= er. If the extension header is not present,
>     use the D= estination IPv6 address.
>     > +\end{itemize}
> =     > +\item Else skip IPv6 extension headers and calculate th= e hash as
>     > +defined for an IPv6 packet without ex= tension headers
>     > +(see \ref{sec:Device Types / Ne= twork Device / Device Operation /
>     Processing of Incom= ing Packets / Hash calculation for incoming packets /
>    = IPv6 packets without extension header}).
>     > +\end{= itemize}
>     > +
>     > +\paragrap= h{Hash reporting for incoming packets}
>     > +\label{s= ec:Device Types / Network Device / Device Operation / Processing
> &n= bsp;   of Incoming Packets / Hash reporting for incoming packets}
&= gt;     > +
>     > +If VIRTIO_NET_F_HASH_R= EPORT was negotiated and
>     > + the device has calcul= ated the hash for the packet, the device fills \
>     fiel= d{hash_type} with the type of calculated hash
>     > +a= nd \field{hash_value} with the value of calculated hash.
>   &nb= sp; > +
>     > +If VIRTIO_NET_F_HASH_REPORT was nego= tiated but due to any reason the
>     > +hash was not c= alculated, the device sets \field{hash_type} to
>     VIRTI= O_NET_HASH_REPORT_NONE.
>     > +
>     = > +Possible values that the device can report in \field{hash_type} are>     defined below.
>     > +They corres= pond to supported hash types defined in
>     > +\ref{se= c:Device Types / Network Device / Device Operation / Processing
> &nb= sp;   of Incoming Packets / Hash calculation for incoming packets / Su= pported/
>     enabled hash types}
>     &g= t; +as follows:
>     > +
>     > +VI= RTIO_NET_HASH_TYPE_XXX =3D 1 << (VIRTIO_NET_HASH_REPORT_XXX - 1)
&= gt;
>
>     So hash_type is the HASH_REPORT value t= hen? That's quite confusing.
>     Let's rename to hash_rep= ort?
>
> No problem to rename anything, but I'd like to do it = one time.
> Currently meaningful hash report values are (1..9), 0 for= none
> They correspond to bitmask of 9 bits for enabled/supported.> It was possible to use the same definitions for enable/support/repor= t
> but then reported kind of hash should be 4 bytes.
> As you = anyway suggests padding at the end of the packet, we can do that,
> i= .e. add (32 bit hash + 32 bit type)

We can but it seems l= ike a waste, does it not? padding can be used for
something later ...

> Or if we stay with the values as they are now:
>= values 0..9 - VIRTIO_NET_WHAT?

I thought that's VIRTIO_N= ET_HASH_REPORT_XXX
OK, this is exactly what is defined=

> bits from 0 to 8 - VIRTIO_NET_WHAT?


and= this one VIRTIO_NET_HASH_TYPE_XXX?
OK, this is a= lso exactly what is defined



Generally what you= did here is a bit unusual. Mostly we just define
bit numbers
 &= nbsp;      #define VIRTIO_SCSI_F_INOUT  =                  0
 &= nbsp;      #define VIRTIO_SCSI_F_HOTPLUG &nbs= p;                1
  =       #define VIRTIO_SCSI_F_CHANGE   &nb= sp;               2
   = ;     #define VIRTIO_SCSI_F_T10_PI     &= nbsp;             3

=
Value 0 of hash_report is "no hash calculated" and it does not
participate in support/enable mask. I did not want to
use value other than zero for "no hash".

So you want bit 0 to be reserved (not used) in enable/support mask
and then to have all the VIRTIO_NET_HASH_TYPE_XXX to be
exactly 1 << VIRTIO_NET_HASH_REPORT_XXX? Just say...
=

and just say that bit numbers are from this table, with bit
0 c= orresponding to the value 0, bit 1 to value 1 etc.


ma= ybe that would have been easier on the eyes - I didn't try,
I'm not even= sure.

But what you have is correct enough, we can always= try to
improve the wording later.


>
> <= br>>     > +
>     > +\begin{lstlisting}=
>     > +#define VIRTIO_NET_HASH_REPORT_NONE   &nb= sp;        0
>     > +#define VIRTIO= _NET_HASH_REPORT_IPv4            1
> &n= bsp;   > +#define VIRTIO_NET_HASH_REPORT_TCPv4      =     2
>     > +#define VIRTIO_NET_HASH_REPORT= _UDPv4           3
>     > +#de= fine VIRTIO_NET_HASH_REPORT_IPv6            4=
>     > +#define VIRTIO_NET_HASH_REPORT_TCPv6   &n= bsp;       5
>     > +#define VIRTIO_NET_= HASH_REPORT_UDPv6           6
>    = ; > +#define VIRTIO_NET_HASH_REPORT_IPv6_EX         = 7
>     > +#define VIRTIO_NET_HASH_REPORT_TCPv6_EX  = ;      8
>     > +#define VIRTIO_NET_HASH= _REPORT_UDPv6_EX        9
>     > +\= end{lstlisting}
>     > +
>     > &nb= sp;\subsubsection{Control Virtqueue}\label{sec:Device Types / Network
&g= t;     Device / Device Operation / Control Virtqueue}
> &nb= sp;   >  
>     >  The driver uses the= control virtqueue (if VIRTIO_NET_F_CTRL_VQ is
>     > @= @ -3896,6 +4064,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device
= >     Types / Network Device / Devi
>     >=  #define VIRTIO_NET_CTRL_MQ    4
>     >=   #define VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET        = 0 (for automatic receive
>     steering)
>   &nb= sp; >   #define VIRTIO_NET_CTRL_MQ_RSS_CONFIG       =    1 (for configurable
>     receive steering)>     > + #define VIRTIO_NET_CTRL_MQ_HASH_CONFIG   &n= bsp;     2 (for configurable hash
>     calculati= on)
>     >  \end{lstlisting}
>    = >  
>     >  If more than one multiqueue m= ode is negotiated, the resulting device
>     configuration= is defined by the last command sent by the driver.
>     &= gt; @@ -3961,10 +4130,37 @@ \subsubsection{Control Virtqueue}\label
>=     {sec:Device Types / Network Device / Devi
>   &nb= sp; >  according to the native endian of the guest rather than
&= gt;     >  (necessarily when not using the legacy interfa= ce) little-endian.
>     >  
>     = > +\subparagraph{Hash calculation}\label{sec:Device Types / Network Devi= ce
>     / Device Operation / Control Virtqueue / Automatic= receive steering in
>     multiqueue mode / Hash calculati= on}
>     > +If VIRTIO_NET_F_HASH_REPORT was negotiated = and the device uses automatic
>     receive steering,
&g= t;     > +the device MUST support a command to configure hash = calculation
>     parameters.
>     > +<= br>>     > +The driver provides parameters for hash calcula= tion as follows:
>     > +
>     > +\= field{class} VIRTIO_NET_CTRL_MQ, \field{command}
>     VIRT= IO_NET_CTRL_MQ_HASH_CONFIG.
>     > +
>   &nb= sp; > +The \field{command-specific-data} has following format:
> &= nbsp;   > +\begin{lstlisting}
>     > +struct vi= rtio_net_hash_config {
>     > +    le32 hash_= types;
>     > +    le16 reserved[4];
> =     > +    u8 hash_key_length;
>    = > +    u8 hash_key_data[hash_key_length];
>   &nbs= p; > +};
>     > +\end{lstlisting}
>   &nb= sp; > +Field \field{hash_types} contains a bitmask of allowed hash types= as
>     > +defined in
>     > +\ref= {sec:Device Types / Network Device / Device Operation / Processing
> =     of Incoming Packets / Hash calculation for incoming packets /= Supported/
>     enabled hash types}.
>    = ; > +Initially the device has all hash types disabled and reports only>     VIRTIO_NET_HASH_REPORT_NONE.
>     >= ; +
>     > +Field \field{reserved} MUST contain zeroes.= It is defined to make the
>     structure to match the lay= out of virtio_net_rss_config structure,
>     > +defined= in \ref{sec:Device Types / Network Device / Device Operation /
> &nb= sp;   Control Virtqueue / Receive-side scaling (RSS)}.
>   =   > +
>     > +Fields \field{hash_key_length} an= d \field{hash_key_data} define the key
>     to be used in = hash calculation.
>     > +
>     > &= nbsp;\paragraph{Receive-side scaling (RSS)}\label{sec:Device Types / Networ= k
>     Device / Device Operation / Control Virtqueue / Rec= eive-side scaling (RSS)}
>     >  A device offers t= he feature VIRTIO_NET_F_RSS if it supports RSS receive
>    = ; steering with Toeplitz hash calculation and configurable parameters.
&= gt;     >  
>     > -A driver queries = RSS capabilities of the device by reading device
>     conf= iguration as defined in \ref{sec:Device Types / Network Device / Device
= >     configuration layout / RSS}
>     > += A driver queries RSS capabilities of the device by reading device
> &= nbsp;   configuration as defined in \ref{sec:Device Types / Network De= vice / Device
>     configuration layout}
>   &n= bsp; >  
>     >  \subparagraph{Setting RSS= parameters}\label{sec:Device Types / Network
>     Device = / Device Operation / Control Virtqueue / Receive-side scaling (RSS)
>=     / Setting RSS parameters}
>     >  <= br>>     > @@ -3981,7 +4177,8 @@ \subsubsection{Control Vir= tqueue}\label{sec:Device
>     Types / Network Device / Dev= i
>     >  };
>     >  \end= {lstlisting}
>     >  Field \field{hash_types} cont= ains a bitmask of allowed hash types as
>     > -defined= in \ref{sec:Device Types / Network Device / Device Operation /
> &nb= sp;   Control Virtqueue / Receive-side scaling (RSS) / RSS hash types}= .
>     > +defined in
>     > +\ref{s= ec:Device Types / Network Device / Device Operation / Processing
> &n= bsp;   of Incoming Packets / Hash calculation for incoming packets / S= upported/
>     enabled hash types}.
>     = >  
>     >  Field \field{indirection_table= _mask} is a mask to be applied to
>     >  the calc= ulated hash to produce an index in the
>     > @@ -3995,= 93 +4192,7 @@ \subsubsection{Control Virtqueue}\label{sec:Device
> &n= bsp;   Types / Network Device / Devi
>     >  =
>     >  A driver sets \field{max_tx_vq} to inform= a device how many transmit
>     virtqueues it may use (tr= ansmitq1\ldots transmitq \field{max_tx_vq}).
>     > &nb= sp;
>     > -\subparagraph{RSS hash types}\label{sec:Dev= ice Types / Network Device /
>     Device Operation / Contr= ol Virtqueue / Receive-side scaling (RSS) / RSS
>     hash = types}
>     > -
>     > -The device = calculates the hash on IPv4 packets according to the
>     = > -field \field{hash_types} of the virtio_net_rss_config structure as>     follows:
>     > -\begin{itemize}>     > -\item If VIRTIO_NET_RSS_HASH_TYPE_TCPv4 is set an= d the packet has
>     > -a TCP header, the hash is calc= ulated over the following fields:
>     > -\begin{itemiz= e}
>     > -\item Source IP address
>    = ; > -\item Destination IP address
>     > -\item Sour= ce TCP port
>     > -\item Destination TCP port
> =     > -\end{itemize}
>     > -\item Else if= VIRTIO_NET_RSS_HASH_TYPE_UDPv4 is set and the
>     > -= packet has a UDP header, the hash is calculated over the following
> =     fields:
>     > -\begin{itemize}
> &= nbsp;   > -\item Source IP address
>     > -\ite= m Destination IP address
>     > -\item Source UDP port<= br>>     > -\item Destination UDP port
>    = ; > -\end{itemize}
>     > -\item Else if VIRTIO_NET_= RSS_HASH_TYPE_IPv4 is set, the hash is
>     > -calculat= ed over the following fields:
>     > -\begin{itemize}>     > -\item Source IP address
>     &g= t; -\item Destination IP address
>     > -\end{itemize}<= br>>     > -\item Else the device does not calculate the ha= sh
>     > -\end{itemize}
>     > ->     > -\label{itm:Device Types / Network Device / Devic= e Operation / Control
>     Virtqueue / Receive-side scalin= g (RSS) / RSS hash types/hash on IPv6
>     packets without= extension headers}
>     > -The device calculates the h= ash on IPv6 packets without extension
>     > -headers a= ccording to the field \field{hash_types} of the
>     virti= o_net_rss_config structure as follows:
>     > -\begin{i= temize}
>     > -\item If VIRTIO_NET_RSS_HASH_TYPE_TCPv6= is set and the packet has
>     > -a TCPv6 header, the = hash is calculated over the following fields:
>     > -\= begin{itemize}
>     > -\item Source IPv6 address
>= ;     > -\item Destination IPv6 address
>     = > -\item Source TCP port
>     > -\item Destination T= CP port
>     > -\end{itemize}
>     >= ; -\item Else if VIRTIO_NET_RSS_HASH_TYPE_UDPv6 is set and the
> &nbs= p;   > -packet has a UDPv6 header, the hash is calculated over the = following
>     fields:
>     > -\begin{= itemize}
>     > -\item Source IPv6 address
> &nbs= p;   > -\item Destination IPv6 address
>     > -= \item Source UDP port
>     > -\item Destination UDP por= t
>     > -\end{itemize}
>     > -\it= em Else if VIRTIO_NET_RSS_HASH_TYPE_IPv6 is set, the hash is
>  =   > -calculated over the following fields:
>     &= gt; -\begin{itemize}
>     > -\item Source IPv6 address<= br>>     > -\item Destination IPv6 address
>   &= nbsp; > -\end{itemize}
>     > -\item Else the device= does not calculate the hash
>     > -\end{itemize}
&= gt;     > -
>     > -The device calculates = the hash on IPv6 packets with extension
>     > -headers= according to the field \field{hash_types} of the
>     vir= tio_net_rss_config structure as follows:
>     > -\begin= {itemize}
>     > -\item If VIRTIO_NET_RSS_HASH_TYPE_TCP= _EX is set and the packet
>     > -has a TCPv6 header, t= he hash is calculated over the following fields:
>     >= -\begin{itemize}
>     > -\item Home address from the h= ome address option in the IPv6 destination
>     options he= ader. If the extension header is not present, use the Source IPv6
> &= nbsp;   address.
>     > -\item IPv6 address that i= s contained in the Routing-Header-Type-2 from
>     the ass= ociated extension header. If the extension header is not present,
> &= nbsp;   use the Destination IPv6 address.
>     > -= \item Source TCP port
>     > -\item Destination TCP por= t
>     > -\end{itemize}
>     > -\it= em Else if VIRTIO_NET_RSS_HASH_TYPE_UDP_EX is set and the
>   &n= bsp; > -packet has a UDPv6 header, the hash is calculated over the follo= wing
>     fields:
>     > -\begin{itemi= ze}
>     > -\item Home address from the home address op= tion in the IPv6 destination
>     options header. If the e= xtension header is not present, use the Source IPv6
>     a= ddress.
>     > -\item IPv6 address that is contained in= the Routing-Header-Type-2 from
>     the associated extens= ion header. If the extension header is not present,
>     u= se the Destination IPv6 address.
>     > -\item Source U= DP port
>     > -\item Destination UDP port
> &nbs= p;   > -\end{itemize}
>     > -\item Else if VIR= TIO_NET_RSS_HASH_TYPE_IP_EX is set, the hash is
>     > = -calculated over the following fields:
>     > -\begin{i= temize}
>     > -\item Home address from the home addres= s option in the IPv6 destination
>     options header. If t= he extension header is not present, use the Source IPv6
>   &nbs= p; address.
>     > -\item IPv6 address that is containe= d in the Routing-Header-Type-2 from
>     the associated ex= tension header. If the extension header is not present,
>   &nbs= p; use the Destination IPv6 address.
>     > -\end{itemi= ze}
>     > -\item Else skip IPv6 extension headers and = calculate the hash as
>     > -defined for an IPv6 packe= t without extension headers (see \ref
>     {itm:Device Typ= es / Network Device / Device Operation / Control Virtqueue /
>  =   Receive-side scaling (RSS) / RSS hash types/hash on IPv6 packets wi= thout
>     extension headers}).
>     >= -\end{itemize}
>     > +Fields \field{hash_key_length} = and \field{hash_key_data} define the key
>     to be used i= n hash calculation.
>     >  
>    = >  \drivernormative{\subparagraph}{Setting RSS parameters}{Device = Types /
>     Network Device / Device Operation / Control V= irtqueue / Receive-side
>     scaling (RSS) }
>  = ;   >  
>     > @@ -4093,12 +4204,12 @@ \su= bsubsection{Control Virtqueue}\label
>     {sec:Device Type= s / Network Device / Devi
>     >  
>   =   >  A driver MUST use \field{indirection_table_mask} values t= hat are less
>     than \field{rss_max_indirection_table_le= ngth} reported by a device.
>     >  
>  = ;   > -A driver MUST NOT set any VIRTIO_NET_RSS_HASH_TYPE_ flags th= at are not
>     supported by a device.
>   &nbs= p; > +A driver MUST NOT set any VIRTIO_NET_HASH_TYPE_ flags that are not=
>     supported by a device.
>     > &n= bsp;
>     >  \devicenormative{\subparagraph}{RSS p= rocessing}{Device Types / Network
>     Device / Device Ope= ration / Control Virtqueue / Receive-side scaling (RSS)
>   &nbs= p; / RSS processing}
>     >  The device MUST deter= mine the destination queue for a network packet as
>     fo= llows:
>     >  \begin{itemize}
>   &nbs= p; > -\item Calculate the hash of the packet as defined in \ref{sec:Devi= ce
>     Types / Network Device / Device Operation / Contro= l Virtqueue /
>     Receive-side scaling (RSS) / RSS hash t= ypes}
>     > +\item Calculate the hash of the packet as= defined in \ref{sec:Device
>     Types / Network Device / = Device Operation / Processing of Incoming Packets
>     / H= ash calculation for incoming packets}.
>     >  \it= em 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).
&= gt;     >  \item Apply \field{indirection_table_mask} to = the calculated hash and
>     use the result as the index i= n the indirection table to get 0-based number
>     of dest= ination receiveq (value of 0 corresponds to receiveq1).
>   &nbs= p; >  \end{itemize}
>     > --
>   &n= bsp; > 2.17.1
>
>
>     This publicly arch= ived list offers a means to provide input to the
>     OASI= S Virtual I/O Device (VIRTIO) TC.
>
>     In order t= o verify user consent to the Feedback License terms and
>   &nbs= p; to minimize spam in the list archive, subscription is required
> &= nbsp;   before posting.
>
>     Subscribe: virt= io-comment-subscribe@lists.oasis-open.org
>     Unsubscribe= : virtio-comment-unsubscribe@lists.oasis-open.org
>     Lis= t help: virtio-comment-help@lists.oasis-open.org
>     List= archive: https://lists.oasis-open.org/archives/virtio-comment/
> &nb= sp;   Feedback License: https://www.oasis-open.org/who/ipr/feedback_li= cense.pdf
>     List Guidelines: https://www.oasis-open.org= /policies-guidelines/
>     mailing-lists
>   &n= bsp; Committee: https://www.oasis-open.org/committees/virtio/
>  = ;   Join OASIS: https://www.oasis-open.org/join/
>
>
= >


------=_Part_7261239_1035068924.1582123777149--