From: "Michael S. Tsirkin" <mst@redhat.com>
To: Yuri Benditovich <ybendito@redhat.com>
Cc: Yuri Benditovich <yuri.benditovich@daynix.com>,
virtio-comment@lists.oasis-open.org
Subject: Re: [virtio-comment] Re: [PATCH v4 1/1] virtio-net: Define per-packet hash reporting feature
Date: Wed, 19 Feb 2020 09:56:04 -0500 [thread overview]
Message-ID: <20200219095236-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <1785864968.7261240.1582123777151.JavaMail.zimbra@redhat.com>
On Wed, Feb 19, 2020 at 09:49:37AM -0500, Yuri Benditovich wrote:
>
>
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
> From: "Michael S. Tsirkin" <mst@redhat.com>
> To: "Yuri Benditovich" <ybendito@redhat.com>
> Cc: "Yuri Benditovich" <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 -0500, Yuri Benditovich wrote:
> >
> >
> >
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> >
> > From: "Michael S. Tsirkin" <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, 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 <yuri.benditovich@daynix.com>
> > > ---
> > > 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
> Types /
> > 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
> hash
> > > + value and a type of calculated hash.
> > > +
> > > \item[VIRTIO_NET_F_GUEST_HDRLEN(59)] Driver can provide the exact
> \field
> > {hdr_len}
> > > value. Device benefits from knowing the exact header length.
> > >
> > > @@ -2995,35 +2998,17 @@ \subsection{Device configuration layout}\
> label
> > {sec:Device Types / Network Device
> > > le32 supported_hash_types;
> > > };
> > > \end{lstlisting}
> > > -\label{sec:Device Types / Network Device / Device configuration
> layout /
> > 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
> 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 specifies the maximal supported length of RSS key in bytes.
> > >
> > > -Field \field{rss_max_key_size} specifies the maximal supported
> length of
> > RSS key in bytes.
> > > +The following field, \field{rss_max_indirection_table_length} only
> exist
> > 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
> device
> > 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
> Virtqueue /
> > 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
> least
> > 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
> packets
> > 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
> Packets}
> > > \label{devicenormative:Device Types / Network Device / Device
> Operation
> > / 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 /
> Processing
> > of Incoming Packets / Hash calculation for incoming packets}
> > > +
> > > +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 VIRTIO_NET_F_HASH_REPORT was negotiated. The
> device
> > 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_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 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_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_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_CONFIG
> > 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 /
> Processing
> > 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 /
> Processing
> > of Incoming Packets / Hash calculation for incoming packets / IPv4
> packets}
> > > +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 /
> Processing
> > of Incoming Packets / Hash calculation for incoming packets / IPv6
> packets
> > 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 /
> Processing
> > of Incoming Packets / Hash calculation for incoming packets / IPv6
> packets
> > 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
> destination
> > 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
> from
> > 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
> destination
> > 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
> from
> > 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
> destination
> > 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
> from
> > 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 /
> Processing
> > 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 /
> Processing
> > of Incoming Packets / Hash calculation for incoming packets /
> Supported/
> > enabled hash types}
> > > +as follows:
> > > +
> > > +VIRTIO_NET_HASH_TYPE_XXX = 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
>
>
> > bits from 0 to 8 - VIRTIO_NET_WHAT?
>
>
> and this one VIRTIO_NET_HASH_TYPE_XXX?
>
> OK, this is also exactly what is defined
>
Right I'm saying what's defined is fine, just call the fields
consistently.
>
>
> 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
> participate in support/enable mask. I did not want to
> use value other than zero for "no hash".
Oh right.
> 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...
>
We can do that too but it's up to you really.
So fixing the below you would say
bit 0 curresponding to value 1,
bit 1 corresponding to value 2 etc.
No bit corresponds to value 0
?
>
> 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:Device
> > 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
> Device
> > / Device Operation / Control Virtqueue / Automatic receive steering
> in
> > multiqueue mode / Hash calculation}
> > > +If VIRTIO_NET_F_HASH_REPORT was negotiated and the device uses
> automatic
> > 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 /
> 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 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 /
> Network
> > Device / Device Operation / Control Virtqueue / Receive-side scaling
> (RSS)}
> > > A device offers the feature VIRTIO_NET_F_RSS if it supports RSS
> receive
> > 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 /
> Device
> > configuration layout / RSS}
> > > +A driver queries RSS capabilities of the device by reading device
> > configuration as defined in \ref{sec:Device Types / Network Device /
> Device
> > configuration layout}
> > >
> > > \subparagraph{Setting RSS parameters}\label{sec:Device Types /
> Network
> > Device / Device Operation / Control Virtqueue / Receive-side scaling
> (RSS)
> > / Setting RSS parameters}
> > >
> > > @@ -3981,7 +4177,8 @@ \subsubsection{Control Virtqueue}\label
> {sec:Device
> > 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 /
> Processing
> > 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:Device
> > 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
> Device /
> > 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 /
> Control
> > 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
> destination
> > 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
> from
> > 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
> destination
> > 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
> from
> > 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
> destination
> > 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
> from
> > 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
> Virtqueue /
> > Receive-side scaling (RSS) / RSS hash types/hash on IPv6 packets
> without
> > 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
> not
> > 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 /
> Network
> > Device / Device Operation / Control Virtqueue / Receive-side scaling
> (RSS)
> > / 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
> 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).
> > > \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.pdf
> > 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/
> >
> >
> >
>
>
>
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.pdf
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/
next prev parent reply other threads:[~2020-02-19 14:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-19 7:53 [virtio-comment] [PATCH v4 0/1] Define VIRTIO_NET_F_HASH_REPORT feature Yuri Benditovich
2020-02-19 7:53 ` [virtio-comment] [PATCH v4 1/1] virtio-net: Define per-packet hash reporting feature Yuri Benditovich
2020-02-19 9:12 ` [virtio-comment] " Michael S. Tsirkin
2020-02-19 11:07 ` Yuri Benditovich
2020-02-19 14:35 ` Michael S. Tsirkin
2020-02-19 14:49 ` Yuri Benditovich
2020-02-19 14:56 ` Michael S. Tsirkin [this message]
2020-02-20 5:09 ` Yuri Benditovich
2020-02-20 6:13 ` Michael S. Tsirkin
2020-02-19 12:27 ` [virtio-comment] " Jason Wang
2020-02-19 14:23 ` Michael S. Tsirkin
2020-02-20 6:38 ` Jason Wang
2020-02-20 7:41 ` Yuri Benditovich
2020-02-20 8:10 ` Michael S. Tsirkin
2020-02-20 8:11 ` Jason Wang
2020-02-20 8:18 ` Michael S. Tsirkin
2020-02-20 8:19 ` Michael S. Tsirkin
2020-02-20 20:06 ` Yuri Benditovich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200219095236-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=ybendito@redhat.com \
--cc=yuri.benditovich@daynix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.