From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from ws5-mx01.kavi.com (ws5-mx01.kavi.com [34.193.7.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F0235C76195 for ; Tue, 21 Mar 2023 03:36:20 +0000 (UTC) Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by ws5-mx01.kavi.com (Postfix) with ESMTP id 570B42B14D for ; Tue, 21 Mar 2023 03:36:18 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 9CBD6986450 for ; Tue, 21 Mar 2023 03:36:17 +0000 (UTC) Received: from host09.ws5.connectedcommunity.org (host09.ws5.connectedcommunity.org [10.110.1.97]) by lists.oasis-open.org (Postfix) with QMQP id 8D7A1986385; Tue, 21 Mar 2023 03:36:17 +0000 (UTC) Mailing-List: contact virtio-comment-help@lists.oasis-open.org; run by ezmlm List-ID: Sender: Precedence: bulk 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 64F28986735 for ; Tue, 21 Mar 2023 03:36:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-MC-Unique: SBm-XO-9MiuKQatiRI1wxw-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679369772; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UzSiWuHEtiyNKaNloLbO/y4Sfiw0outKM53whSEnkxk=; b=ZnqVnRhviqOSpOlRVOxMg5yxokiW7jmz9BjqTedg+Uw21lYMZsnkhy/DAzhm4dLAux 2Ob5Mn7AyTzit7WZ1K1spzxQ1Te09HyGQMtaj9v6UVHdRonkGoYKtV+6oSo8gwepNx2Z 0PZqVz7W+uujyPaNxYUiuJHzH6UaW6/9IhMzM8NAGx+Z/C2RXuW3serBy1NKEHqerO3U SPUduIuTB8kg7KFyTgKWaK1OZiGptRw+bn4ToHW9GYTUF7qejRMsf9JHXrFyouoo1JoC uVy1/Cx+ucUWfZ06yuryN70Fk4yXwb7pZtFWzqyTIAkG6hSl+xGMGj0dXXo8SpNey0VQ 2G+A== X-Gm-Message-State: AO0yUKX808fty7zKvI2oZWtG2oYLQBavfRRmim4v+ZFg0FOsOCk2Sypf eeRTumYO14ZX+UmryTp9yt3YTllL1uKidB84qOtMvzlsc70+iAXT9ZIrfjy9kyjwXg9OgkPWnzY Dn5Nk58SLVIRWEYJAs9BetniPVO4mpZBD6Sg0j0z4Um9NU9Lrkw== X-Received: by 2002:a05:6870:17aa:b0:177:b9c0:bcba with SMTP id r42-20020a05687017aa00b00177b9c0bcbamr256011oae.3.1679369771954; Mon, 20 Mar 2023 20:36:11 -0700 (PDT) X-Google-Smtp-Source: AK7set/owqCKH2dvg1g8ssmPAvaMBB52iYNtjESflqBj5M2oAwUJthFTzWim3V5OpzJwAzpih+9UPAwlxrIKWCV3zLY= X-Received: by 2002:a05:6870:17aa:b0:177:b9c0:bcba with SMTP id r42-20020a05687017aa00b00177b9c0bcbamr256000oae.3.1679369771258; Mon, 20 Mar 2023 20:36:11 -0700 (PDT) MIME-Version: 1.0 References: <20230320111840.64039-1-hengqi@linux.alibaba.com> <20230320144625-mutt-send-email-mst@kernel.org> In-Reply-To: <20230320144625-mutt-send-email-mst@kernel.org> From: Jason Wang Date: Tue, 21 Mar 2023 11:35:59 +0800 Message-ID: To: "Michael S. Tsirkin" Cc: Heng Qi , virtio-dev@lists.oasis-open.org, virtio-comment@lists.oasis-open.org, Parav Pandit , Yuri Benditovich , Xuan Zhuo X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [virtio-comment] Re: [PATCH v11] virtio-net: support inner header hash On Tue, Mar 21, 2023 at 3:43=E2=80=AFAM Michael S. Tsirkin = wrote: > > On Mon, Mar 20, 2023 at 07:18:40PM +0800, Heng Qi wrote: > > 1. Currently, a received encapsulated packet has an outer and an inner = header, but > > the virtio device is unable to calculate the hash for the inner header.= Multiple > > flows with the same outer header but different inner headers are steere= d to the > > same receive queue. This results in poor receive performance. > > > > To address this limitation, a new feature VIRTIO_NET_F_HASH_TUNNEL has = been > > introduced, which enables the device to advertise the capability to cal= culate the > > hash for the inner packet header. Compared with the out header hash, it= regains > > better receive performance. > > So this would be a very good argument however the cost would be it would > seem we have to keep extending this indefinitely as new tunneling > protocols come to light. > But I believe in fact we don't at least for this argument: > the standard way to address this is actually by propagating entropy > from inner to outer header. Things would be more complicated when multiple layers of tunneling are being used. > > So I'd maybe reorder the commit log and give the explanation 2 below > then say "for some legacy systems > including entropy in IP header > as done in modern protocols is not practical, resulting in > bad performance under RSS". > > > > 2. The same flow can traverse through different tunnels, resulting in t= he encapsulated > > packets being spread across multiple receive queues (refer to the figur= e below). > > However, in certain scenarios, it becomes necessary to direct these enc= apsulated > > packets of the same flow to a single receive queue. This facilitates th= e processing > > of the flow by the same CPU to improve performance (warm caches, less l= ocking, etc.). > > > > client1 client2 > > | | > > | +-------+ | > > +------->|tunnels|<--------+ > > +-------+ > > | | > > | | > > v v > > +-----------------+ > > | processing host | > > +-----------------+ > > necessary is too strong a word I feel. > All this is, is an optimization, we don't really know how strong it is > even. > > Here's how I understand this: > > Imagine two clients client1 and client2 talking to each other. > A copy of all packets is sent to a processing host over a virtio device. > Two directions of the same flow between two clients might be > encapsulated in two different tunnels, with current RSS > strategies they would land on two arbitrary, unrelated queues. > As an optimization, some hosts might wish to make sure both directions > of the encapsulated flow land on the same queue. > > > Is this a good summary? > > > Now that things begin to be clearer, I kind of begin to agree with > Jason's suggestion that this is extremely narrow. And what if I want > one direction on queue1 and another one queue2 e.g. adjacent numbers for > the same flow? If enough people agree this is needed we can accept this > but did you at all consider using something programmable like BPF for > this? Considering we are putting not insignificant amount of work into > this, making this widely useful would be better than a narrow > optimization for a very specific usecase. +1 > > > > To achieve this, the device can calculate a symmetric hash based on the= inner packet > > headers of the flow. The symmetric hash disregards the order of the 5-t= uple when > > computing the hash. > > when you say symmetric hash you really mean symmetric key for toeplitz, y= es? > It's not that it disregards order, it just gives the same result if > you reverse source and destination, no? > > > > Reviewed-by: Jason Wang I'd like to drop my reviewed-by since the patch differs from the one that I reviewed in many places. Thanks > > Signed-off-by: Heng Qi > > Reviewed-by: Xuan Zhuo > > --- > > v10->v11: > > 1. Revise commit log for clarity for readers. > > 2. Some modifications to avoid undefined terms. @Parav Pandit > > 3. Change VIRTIO_NET_F_HASH_TUNNEL dependency. @Parav Pandit > > 4. Add the normative statements. @Parav Pandit > > > > v9->v10: > > 1. Removed hash_report_tunnel related information. @Parav Pandit > > 2. Re-describe the limitations of QoS for tunneling. > > 3. Some clarification. > > > > v8->v9: > > 1. Merge hash_report_tunnel_types into hash_report. @Parav Pandit > > 2. Add tunnel security section. @Michael S . Tsirkin > > 3. Add VIRTIO_NET_F_HASH_REPORT_TUNNEL. > > 4. Fix some typos. > > 5. Add more tunnel types. @Michael S . Tsirkin > > > > v7->v8: > > 1. Add supported_hash_tunnel_types. @Jason Wang, @Parav Pandit > > 2. Change hash_report_tunnel to hash_report_tunnel_types. @Parav = Pandit > > 3. Removed re-definition for inner packet hashing. @Parav Pandit > > 4. Fix some typos. @Michael S . Tsirkin > > 5. Clarify some sentences. @Michael S . Tsirkin > > > > v6->v7: > > 1. Modify the wording of some sentences for clarity. @Michael S. = Tsirkin > > 2. Fix some syntax issues. @Michael S. Tsirkin > > > > v5->v6: > > 1. Fix some syntax and capitalization issues. @Michael S. Tsirkin > > 2. Use encapsulated/encaptulation uniformly. @Michael S. Tsirkin > > 3. Move the links to introduction section. @Michael S. Tsirkin > > 4. Clarify some sentences. @Michael S. Tsirkin > > > > v4->v5: > > 1. Clarify some paragraphs. @Cornelia Huck > > 2. Fix the u8 type. @Cornelia Huck > > > > v3->v4: > > 1. Rename VIRTIO_NET_F_HASH_GRE_VXLAN_GENEVE_INNER to VIRTIO_NET_= F_HASH_TUNNEL. @Jason Wang > > 2. Make things clearer. @Jason Wang @Michael S. Tsirkin > > 3. Keep the possibility to use inner hash for automatic receive s= teering. @Jason Wang > > 4. Add the "Tunnel packet" paragraph to avoid repeating the GRE e= tc. many times. @Michael S. Tsirkin > > > > v2->v3: > > 1. Add a feature bit for GRE/VXLAN/GENEVE inner hash. @Jason Wang > > 2. Chang \field{hash_tunnel} to \field{hash_report_tunnel}. @Jaso= n Wang, @Michael S. Tsirkin > > > > v1->v2: > > 1. Remove the patch for the bitmask fix. @Michael S. Tsirkin > > 2. Clarify some paragraphs. @Jason Wang > > 3. Add \field{hash_tunnel} and VIRTIO_NET_HASH_REPORT_GRE. @Yuri = Benditovich > > > > device-types/net/description.tex | 119 +++++++++++++++++++++++- > > device-types/net/device-conformance.tex | 1 + > > device-types/net/driver-conformance.tex | 1 + > > introduction.tex | 24 +++++ > > 4 files changed, 144 insertions(+), 1 deletion(-) > > > > diff --git a/device-types/net/description.tex b/device-types/net/descri= ption.tex > > index 0500bb6..49dee2f 100644 > > --- a/device-types/net/description.tex > > +++ b/device-types/net/description.tex > > @@ -83,6 +83,9 @@ \subsection{Feature bits}\label{sec:Device Types / Ne= twork Device / Feature bits > > \item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through control > > channel. > > > > +\item[VIRTIO_NET_F_HASH_TUNNEL(52)] Device supports inner packet heade= r hash > > + for tunnel-encapsulated packets. > > + > > \item[VIRTIO_NET_F_NOTF_COAL(53)] Device supports notifications coales= cing. > > > > \item[VIRTIO_NET_F_GUEST_USO4 (54)] Driver can receive USOv4 packets. > > @@ -139,6 +142,7 @@ \subsubsection{Feature bit requirements}\label{sec:= Device Types / Network Device > > \item[VIRTIO_NET_F_NOTF_COAL] Requires VIRTIO_NET_F_CTRL_VQ. > > \item[VIRTIO_NET_F_RSC_EXT] Requires VIRTIO_NET_F_HOST_TSO4 or VIRTIO_= NET_F_HOST_TSO6. > > \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ. > > +\item[VIRTIO_NET_F_HASH_TUNNEL] Requires VIRTIO_NET_F_CTRL_VQ along wi= th VIRTIO_NET_F_RSS and/or VIRTIO_NET_F_HASH_REPORT. > > \end{description} > > > > \subsubsection{Legacy Interface: Feature bits}\label{sec:Device Types = / Network Device / Feature bits / Legacy Interface: Feature bits} > > @@ -198,6 +202,7 @@ \subsection{Device configuration layout}\label{sec:= Device Types / Network Device > > u8 rss_max_key_size; > > le16 rss_max_indirection_table_length; > > le32 supported_hash_types; > > + le32 supported_tunnel_hash_types; > > }; > > \end{lstlisting} > > The following field, \field{rss_max_key_size} only exists if VIRTIO_NE= T_F_RSS or VIRTIO_NET_F_HASH_REPORT is set. > > @@ -212,6 +217,12 @@ \subsection{Device configuration layout}\label{sec= :Device Types / Network Device > > Field \field{supported_hash_types} contains the bitmask of supported h= ash types. > > See \ref{sec:Device Types / Network Device / Device Operation / Proces= sing of Incoming Packets / Hash calculation for incoming packets / Supporte= d/enabled hash types} for details of supported hash types. > > > > +The next field, \field{supported_tunnel_hash_types} only exists if the= device > > +supports inner packet header hash, i.e. if VIRTIO_NET_F_HASH_TUNNEL is= set. > > + > > +Field \field{supported_tunnel_hash_types} contains the bitmask of supp= orted tunnel hash types. > > +See \ref{sec:Device Types / Network Device / Device Operation / Proces= sing of Incoming Packets / Hash calculation for incoming packets / Supporte= d/enabled tunnel hash types} for details of supported tunnel hash types. > > + > > \devicenormative{\subsubsection}{Device configuration layout}{Device T= ypes / Network Device / Device configuration layout} > > > > The device MUST set \field{max_virtqueue_pairs} to between 1 and 0x800= 0 inclusive, > > @@ -848,6 +859,7 @@ \subsubsection{Processing of Incoming Packets}\labe= l{sec:Device Types / Network > > 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 \field{hash_tunnel_types} of the virtio_net_rss_= config structure as 'Enabled hash tunnel types' bitmask if VIRTIO_NET_F_HAS= H_TUNNEL was negotiated. > > \item The device uses a key as defined in \field{hash_key_data} and \f= ield{hash_key_length} of the virtio_net_rss_config structure (see > > \ref{sec:Device Types / Network Device / Device Operation / Control Vi= rtqueue / Receive-side scaling (RSS) / Setting RSS parameters}). > > \end{itemize} > > @@ -855,6 +867,7 @@ \subsubsection{Processing of Incoming Packets}\labe= l{sec:Device Types / Network > > 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 \field{hash_tunnel_types} of the virtio_net_hash= _config structure as 'Enabled hash tunnel types' bitmask if VIRTIO_NET_F_HA= SH_TUNNEL was negotiated. > > \item The device uses a key as defined in \field{hash_key_data} and \f= ield{hash_key_length} of the virtio_net_hash_config structure (see > > \ref{sec:Device Types / Network Device / Device Operation / Control Vi= rtqueue / Automatic receive steering in multiqueue mode / Hash calculation}= ). > > \end{itemize} > > @@ -870,6 +883,8 @@ \subsubsection{Processing of Incoming Packets}\labe= l{sec:Device Types / Network > > > > \subparagraph{Supported/enabled hash types} > > \label{sec:Device Types / Network Device / Device Operation / Processi= ng of Incoming Packets / Hash calculation for incoming packets / Supported/= enabled hash types} > > +This paragraph relies on definitions from \hyperref[intro:IP]{[IP]}, > > +\hyperref[intro:UDP]{[UDP]} and \hyperref[intro:TCP]{[TCP]}. > > Hash types applicable for IPv4 packets: > > \begin{lstlisting} > > #define VIRTIO_NET_HASH_TYPE_IPv4 (1 << 0) > > @@ -980,6 +995,99 @@ \subsubsection{Processing of Incoming Packets}\lab= el{sec:Device Types / Network > > (see \ref{sec:Device Types / Network Device / Device Operation / Proce= ssing of Incoming Packets / Hash calculation for incoming packets / IPv6 pa= ckets without extension header}). > > \end{itemize} > > > > +\paragraph{Inner Packet Header Hash} > > +If the driver negotiates the VIRTIO_NET_F_HASH_TUNNEL feature, it can = configure the > > +hash parameters (including \field{hash_tunnel_types}) for inner packet= header hash > > +through the VIRTIO_NET_CTRL_MQ_HASH_CONFIG or the VIRTIO_NET_CTRL_RSS_= CONFIG command. > > +If multiple commands are sent, the device configuration will be define= d by the last command received. > > + > > +If a specific encapsulation type is set in \field{hash_tunnel_types}, = the device will calculate the > > +hash on the inner packet header of the encapsulated packet (See \ref{s= ec:Device Types > > +/ Network Device / Device OperatiHn / Processing of Incoming Packets / > > +Hash calculation for incoming packets / Tunnel/Encapsulated packet}). = If the encapsulation > > +type is not included in \field{hash_tunnel_types} or the value of \fie= ld{hash_tunnel_types} > > +is VIRTIO_NET_HASH_TUNNEL_TYPE_NONE, the device calculates the hash on= the outer header. > > + > > +\field{hash_tunnel_types} is set to VIRTIO_NET_HASH_TUNNEL_TYPE_NONE b= y the device for non-encapsulated packets. > > + > > +\subparagraph{Tunnel/Encapsulated packet} > > +\label{sec:Device Types / Network Device / Device Operation / Processi= ng of Incoming Packets / Hash calculation for incoming packets / Tunnel/Enc= apsulated packet} > > +A tunnel packet is encapsulated from the original packet based on the = tunneling > > +protocol (only a single level of encapsulation is currently supported)= . The > > +encapsulated packet contains an outer header and an inner header, and = the device > > +calculates the hash over either the inner header or the outer header. > > + > > +When the feature VIRTIO_NET_F_HASH_TUNNEL is negotiated and a received= encapsulated > > +packet's outer header matches one of the supported \field{hash_tunnel_= types}, > > +the hash of the inner header is calculated. Supported encapsulation ty= pes are listed > > +in \ref{sec:Device Types / Network Device / Device Operation / Process= ing of Incoming > > +Packets / Hash calculation for incoming packets / Supported/enabled ha= sh tunnel types}. > > + > > +Some encapsulated packet types: \hyperref[intro:GRE]{[GRE]}, \hyperref= [intro:VXLAN]{[VXLAN]}, > > +\hyperref[intro:GENEVE]{[GENEVE]}, \hyperref[intro:IPIP]{[IPIP]} and \= hyperref[intro:NVGRE]{[NVGRE]}. > > + > > +\subparagraph{Supported/enabled tunnel hash types} > > +\label{sec:Device Types / Network Device / Device Operation / Processi= ng of Incoming Packets / Hash calculation for incoming packets / Supported/= enabled tunnel hash types} > > +If the feature VIRTIO_NET_F_HASH_TUNNEL is negotiated and \field{hash_= tunnel_types} > > +is set to VIRTIO_NET_HASH_TUNNEL_TYPE_NONE, the device calculates the = hash using the > > +outer header of the encapsulated packet. > > +\begin{lstlisting} > > +#define VIRTIO_NET_HASH_TUNNEL_TYPE_NONE (1 << 0) > > +\end{lstlisting} > > + > > +The encapsulation hash type below indicates that the hash is calculate= d over the > > +inner packet header: > > +Hash type applicable for inner payload of the gre-encapsulated packet > > +\begin{lstlisting} > > +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GRE (1 << 1) > > +\end{lstlisting} > > +Hash type applicable for inner payload of the vxlan-encapsulated packe= t > > +\begin{lstlisting} > > +#define VIRTIO_NET_HASH_TUNNEL_TYPE_VXLAN (1 << 2) > > +\end{lstlisting} > > +Hash type applicable for inner payload of the geneve-encapsulated pack= et > > +\begin{lstlisting} > > +#define VIRTIO_NET_HASH_TUNNEL_TYPE_GENEVE (1 << 3) > > +\end{lstlisting} > > +Hash type applicable for inner payload of the ip-encapsulated packet > > +\begin{lstlisting} > > +#define VIRTIO_NET_HASH_TUNNEL_TYPE_IPIP (1 << 4) > > +\end{lstlisting} > > +Hash type applicable for inner payload of the nvgre-encapsulated packe= t > > +\begin{lstlisting} > > +#define VIRTIO_NET_HASH_TUNNEL_TYPE_NVGRE (1 << 5) > > +\end{lstlisting} > > + > > +\subparagraph{Tunnel QoS limitation} > > +When a specific receive queue is shared by multiple tunnels to receive= encapsulated packets, > > +there is no quality of service (QoS) for these packets. For example, w= hen the packets of certain > > +tunnels are spread across multiple receive queues, these receive queue= s may have an unbalanced > > +amount of packets. This can cause a specific receive queue to become f= ull, resulting in packet loss. > > + > > +Possible mitigations: > > +\begin{itemize} > > +\item Use a tool with good forwarding performance to keep the receive = queue from filling up. > > +\item If the QoS is unavailable, the driver can set \field{hash_tunnel= _types} to VIRTIO_NET_HASH_TUNNEL_TYPE_NONE > > + to disable inner packet hash for encapsulated packets. > > +\item Choose a hash key that can avoid queue collisions. > > +\item Perform appropriate QoS before packets consume the receive buffe= rs of the receive queues. > > +\end{itemize} > > + > > +The limitations mentioned above exist with/without the inner packer he= ader hash. > > + > > +\devicenormative{\subparagraph}{Inner Packet Header Hash}{Device Types= / Network Device / Device Operation / Control Virtqueue / Inner Packet Hea= der Hash} > > + > > +The device MUST calculate the outer packet hash if the received encaps= ulated packet has an encapsulation type not in \field{supported_tunnel_hash= _types}. > > + > > +The device MUST drop the encapsulated packet if the destination receiv= e queue is being reset. > > I'm not sure how this last one got here. It seems to have nothing to do > with encapsulation - if we want to we should require this for all > packets or none at all. > > > > +\drivernormative{\subparagraph}{Inner Packet Header Hash}{Device Types= / Network Device / Device Operation / Control Virtqueue / Inner Packet Hea= der Hash} > > + > > +If the driver does not negotiate the VIRTIO_NET_F_HASH_TUNNEL feature,= it MUST set \field{hash_tunnel_types} > > +to VIRTIO_NET_HASH_TUNNEL_TYPE_NONE before issuing the command VIRTIO_= NET_CTRL_MQ_HASH_CONFIG or VIRTIO_NET_CTRL_RSS_CONFIG. > > + > > +The driver MUST set \field{hash_tunnel_types} to the encapsulation typ= es supported by the device. > > unclear. seems to mean all types must be approved > where you really mean "only those types". original for non tunnel is: > > A driver MUST NOT set any VIRTIO_NET_HASH_TYPE_ flags that are not suppor= ted by a device. > > which is clear though a bit verbose with two negations. > > Also here it says "supported" but below it says "allowed". > > > > > \paragraph{Hash reporting for incoming packets} > > \label{sec:Device Types / Network Device / Device Operation / Processi= ng of Incoming Packets / Hash reporting for incoming packets} > > > > @@ -1392,12 +1500,17 @@ \subsubsection{Control Virtqueue}\label{sec:Dev= ice Types / Network Device / Devi > > le16 reserved[4]; > > u8 hash_key_length; > > u8 hash_key_data[hash_key_length]; > > + le32 hash_tunnel_types; > > }; > > Hmm this fixed type after variable type is problematic - might > become unaligned. We could use some of reserved[4] > for this ... > > > > > \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/en= abled hash types}. > > -Initially the device has all hash types disabled and reports only VIRT= IO_NET_HASH_REPORT_NONE. > > + > > +Field \field{hash_tunnel_types} contains a bitmask of allowed hash tun= nel types as > > +defined in \ref{sec:Device Types / Network Device / Device Operation /= Processing of Incoming Packets / Hash calculation for incoming packets / S= upported/enabled hash tunnel types}. > > + > > +Initially the device has all hash types and hash tunnel 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)}. > > @@ -1421,6 +1534,7 @@ \subsubsection{Control Virtqueue}\label{sec:Devic= e Types / Network Device / Devi > > le16 max_tx_vq; > > u8 hash_key_length; > > u8 hash_key_data[hash_key_length]; > > + le32 hash_tunnel_types; > > > Same alignment problem here but I'm not sure how to solve it. > Suggestions? > > > }; > > \end{lstlisting} > > Field \field{hash_types} contains a bitmask of allowed hash types as > > @@ -1441,6 +1555,9 @@ \subsubsection{Control Virtqueue}\label{sec:Devic= e Types / Network Device / Devi > > > > Fields \field{hash_key_length} and \field{hash_key_data} define the ke= y to be used in hash calculation. > > > > +Field \field{hash_tunnel_types} contains a bitmask of allowed hash tun= nel types as > > +defined in \ref{sec:Device Types / Network Device / Device Operation /= Processing of Incoming Packets / Hash calculation for incoming packets / S= upported/enabled hash tunnel types}. > > + > > \drivernormative{\subparagraph}{Setting RSS parameters}{Device Types /= Network Device / Device Operation / Control Virtqueue / Receive-side scali= ng (RSS) } > > > > A driver MUST NOT send the VIRTIO_NET_CTRL_MQ_RSS_CONFIG command if th= e feature VIRTIO_NET_F_RSS has not been negotiated. > > diff --git a/device-types/net/device-conformance.tex b/device-types/net= /device-conformance.tex > > index 54f6783..0ff5944 100644 > > --- a/device-types/net/device-conformance.tex > > +++ b/device-types/net/device-conformance.tex > > @@ -14,4 +14,5 @@ > > \item \ref{devicenormative:Device Types / Network Device / Device Oper= ation / Control Virtqueue / Automatic receive steering in multiqueue mode} > > \item \ref{devicenormative:Device Types / Network Device / Device Oper= ation / Control Virtqueue / Receive-side scaling (RSS) / RSS processing} > > \item \ref{devicenormative:Device Types / Network Device / Device Oper= ation / Control Virtqueue / Notifications Coalescing} > > +\item \ref{devicenormative:Device Types / Network Device / Device Oper= ation / Control Virtqueue / Inner Packet Header Hash} > > \end{itemize} > > diff --git a/device-types/net/driver-conformance.tex b/device-types/net= /driver-conformance.tex > > index 97d0cc1..951be89 100644 > > --- a/device-types/net/driver-conformance.tex > > +++ b/device-types/net/driver-conformance.tex > > @@ -14,4 +14,5 @@ > > \item \ref{drivernormative:Device Types / Network Device / Device Oper= ation / Control Virtqueue / Offloads State Configuration / Setting Offloads= State} > > \item \ref{drivernormative:Device Types / Network Device / Device Oper= ation / Control Virtqueue / Receive-side scaling (RSS) } > > \item \ref{drivernormative:Device Types / Network Device / Device Oper= ation / Control Virtqueue / Notifications Coalescing} > > +\item \ref{drivernormative:Device Types / Network Device / Device Oper= ation / Control Virtqueue / Inner Packet Header Hash} > > \end{itemize} > > diff --git a/introduction.tex b/introduction.tex > > index 287c5fc..25c9d48 100644 > > --- a/introduction.tex > > +++ b/introduction.tex > > @@ -99,6 +99,30 @@ \section{Normative References}\label{sec:Normative R= eferences} > > Standards for Efficient Cryptography Group(SECG), ``SEC1: Elliptic= Cureve Cryptography'', Version 1.0, September 2000. > > \newline\url{https://www.secg.org/sec1-v2.pdf}\\ > > > > + \phantomsection\label{intro:GRE}\textbf{[GRE]} & > > + Generic Routing Encapsulation > > + \newline\url{https://datatracker.ietf.org/doc/rfc2784/}\\ > > This is GRE over IPv4. > So we are not supporting GRE over IPv6? > > And we do not support optional keys? > > > > > + \phantomsection\label{intro:VXLAN}\textbf{[VXLAN]} & > > + Virtual eXtensible Local Area Network > > + \newline\url{https://datatracker.ietf.org/doc/rfc7348/}\\ > > + \phantomsection\label{intro:GENEVE}\textbf{[GENEVE]} & > > + Generic Network Virtualization Encapsulation > > + \phantomsection\label{intro:IPIP}\textbf{[IPIP]} & > > + IP Encapsulation within IP > > + \newline\url{https://www.rfc-editor.org/rfc/rfc2003}\\ > > + \phantomsection\label{intro:IPIP}\textbf{[NVGRE]} & > > + NVGRE: Network Virtualization Using Generic Routing Encapsulation > > + \newline\url{https://www.rfc-editor.org/rfc/rfc7637.html}\\ > > + \newline\url{https://datatracker.ietf.org/doc/rfc8926/}\\ > > + \phantomsection\label{intro:IP}\textbf{[IP]} & > > + INTERNET PROTOCOL > > + \newline\url{https://www.rfc-editor.org/rfc/rfc791}\\ > > + \phantomsection\label{intro:UDP}\textbf{[UDP]} & > > + User Datagram Protocol > > + \newline\url{https://www.rfc-editor.org/rfc/rfc768}\\ > > + \phantomsection\label{intro:TCP}\textbf{[TCP]} & > > + TRANSMISSION CONTROL PROTOCOL > > + \newline\url{https://www.rfc-editor.org/rfc/rfc793}\\ > > \end{longtable} > > > > \section{Non-Normative References} > > -- > > 2.19.1.6.gb485710b > This publicly archived list offers a means to provide input to the=0D OASIS Virtual I/O Device (VIRTIO) TC.=0D =0D In order to verify user consent to the Feedback License terms and=0D to minimize spam in the list archive, subscription is required=0D before posting.=0D =0D Subscribe: virtio-comment-subscribe@lists.oasis-open.org=0D Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org=0D List help: virtio-comment-help@lists.oasis-open.org=0D List archive: https://lists.oasis-open.org/archives/virtio-comment/=0D Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf=0D List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists=0D Committee: https://www.oasis-open.org/committees/virtio/=0D Join OASIS: https://www.oasis-open.org/join/