[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Re: [PATCH 2/2] virtio_net: support inner header hash for GRE-encapsulated packets
On Thu, Nov 17, 2022 at 3:49 PM Heng Qi <hengqi@linux.alibaba.com> wrote: > > > > å 2022/11/17 äå2:09, Jason Wang åé: > > On Thu, Nov 17, 2022 at 2:00 PM Heng Qi <hengqi@linux.alibaba.com> wrote: > >> > >> > >> å 2022/11/17 äå1:34, Jason Wang åé: > >>> On Thu, Nov 17, 2022 at 1:01 PM Heng Qi <hengqi@linux.alibaba.com> wrote: > >>>> > >>>> å 2022/11/17 äå12:29, Jason Wang åé: > >>>>> On Thu, Nov 17, 2022 at 10:53 AM Heng Qi <hengqi@linux.alibaba.com> wrote: > >>>>>> å 2022/11/17 äå7:32, Yuri Benditovich åé: > >>>>>>> I would suggest to specify also the hash type the device should report > >>>>>>> in case the hash reporting feature is enabled. For example, should the > >>>>>>> device specify somehow in the report that the hash was calculated on > >>>>>>> the inner header or on the regular header? > >>>>>> It seems unnecessary. The calculation of RSS hash using the regular or > >>>>>> inner header is actually > >>>>>> transparent to the driver, and after the hash value and hash type > >>>>>> calculated by the device, > >>>>>> the feedback on skb is that skb only has L4 or L3 hash boolean type. > >>>>> I think what Yuri meant is what if the user wants to calculate hash > >>>>> based on the inner header? Do we need VIRTIO_NET_HASH_TYPE_GRE_XXX? > >>>> Yes, if the user wants to calculate the hash on the inner header, then > >>>> we need VIRTIO_NET_HASH_TYPE_GRE_INNER, > >>>> if the user wants to calculate the hash on the outer header, then we > >>>> donât need to use VIRTIO_NET_HASH_TYPE_GRE_INNER, > >>>> just keep the previous default behavior. > >>> I actually meant should we add VIRTIO_NET_HASH_REPORT_GRE_XXX? > >> VIRTIO_NET_HASH_REPORT_GRE_XXX does not seem to need to be added. > >> > >> _HASH_TYPE_GRE_INNER is a special hash type, which is used in > >> combination with other hash types, > >> indicating that the sd, sdfn, etc. of the inner or outer header are used > >> to calculate the hash. > >> The device can report the following true types to the driver to meet the > >> subsequent requirements of driver. > >> > >> \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} > >> > >> As for whether the device uses the outer or inner header to calculate > >> the hash information, > >> the driver does not seem to need to know? > > We can't assume the behaviour of the driver actually. E.g driver may > > try to do rx classification based on the rxhash. > > Ok, I think this is reasonable and we shouldn't hide certain information. > > Then I'll add VIRTIO_NET_HASH_REPORT_GRE_INNER, considering that > \field{hash_types} is a 32-bit bitmap, > and \field{hash_report} is a 16-bit integer, in order to be compatible > with existing hash computing devices, > we can use the first 8 bits of \field{hash_report} as a tunnel-related > flag, and the last 8 bits of \field{hash_report} > represent the hash five-tuple, e.g. VIRTIO_NET_HASH_TYPE_TCPv4. > > That is, if the value of the obtained \field{hash_report} is greater > than 256, it means that the driver wants > the device to calculate the hash for the inner header of the > tunnel-encapsulated packet . And if the value is less > than 256, the default outer header hashing will be performed. > > Do you think this proposal is feasible?ð Any advantages of this over simply making padding_reserved a part of the hash report? Thanks > > Thanks. > > > > > Thanks > > > >> Thanks. > >> > >>> Thanks > >>> > >>>> This is a configurable hash specification. > >>>> > >>>> Thanks. > >>>> > >>>>> Thanks > >>>>> > >>>>>> Thanks. > >>>>>> > >>>>>>> On Thu, Nov 10, 2022 at 5:41 AM Heng Qi <hengqi@linux.alibaba.com> wrote: > >>>>>>>> å 2022/11/10 äå11:35, Jason Wang åé: > >>>>>>>>> On Wed, Nov 9, 2022 at 7:33 PM Heng Qi <hengqi@linux.alibaba.com> wrote: > >>>>>>>>>> From: Heng Qi <henqqi@linux.alibaba.com> > >>>>>>>>>> > >>>>>>>>>> When VIRTIO_NET_F_RSS is negotiated and the tunnel is used to > >>>>>>>>>> encapsulate the packets, the hash calculated using the outer header > >>>>>>>>>> of the receive packets is always fixed for the same flow packets, > >>>>>>>>>> i.e. they will be steered to the same receive queue. > >>>>>>>>>> > >>>>>>>>>> We add a VIRTIO_NET_HASH_TYPE_GRE_INNER bitmask in \field{hash_types}, > >>>>>>>>>> which instructs the device to calculate the hash using the inner headers > >>>>>>>>>> of GRE-encapsulated packets. > >>>>>>>>>> > >>>>>>>>>> Signed-off-by: Heng Qi <henqqi@linux.alibaba.com> > >>>>>>>>>> Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> > >>>>>>>>>> --- > >>>>>>>>>> content.tex | 116 ++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>>>>>>>>> 1 file changed, 116 insertions(+) > >>>>>>>>>> > >>>>>>>>>> diff --git a/content.tex b/content.tex > >>>>>>>>>> index 6fabf1d..319d401 100644 > >>>>>>>>>> --- a/content.tex > >>>>>>>>>> +++ b/content.tex > >>>>>>>>>> @@ -3883,6 +3883,10 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network > >>>>>>>>>> #define VIRTIO_NET_HASH_TYPE_TCP_EX (1 << 7) > >>>>>>>>>> #define VIRTIO_NET_HASH_TYPE_UDP_EX (1 << 8) > >>>>>>>>>> \end{lstlisting} > >>>>>>>>>> +Hash types applicable to inner payloads of GRE-encapsulated packets > >>>>>>>>>> +\begin{lstlisting} > >>>>>>>>>> +#define VIRTIO_NET_HASH_TYPE_GRE_INNER (1 << 9) > >>>>>>>>>> +\end{lstlisting} > >>>>>>>>>> > >>>>>>>>>> \subparagraph{IPv4 packets} > >>>>>>>>>> \label{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets / Hash calculation for incoming packets / IPv4 packets} > >>>>>>>>>> @@ -3975,6 +3979,114 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network > >>>>>>>>>> (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} > >>>>>>>>>> > >>>>>>>>>> +\subparagraph{Inner payloads of GRE-encapsulated packets} > >>>>>>>>>> +\label{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets / Hash calculation for incoming packets / Inner payloads of GRE-encapsulated packets}} > >>>>>>>>>> +VIRTIO_NET_HASH_TYPE_GRE_INNER bit MUST be set at the same time as one of > >>>>>>>>>> +the bits between VIRTIO_NET_HASH_TYPE_IPv4 and VIRTIO_NET_HASH_TYPE_UDP_EX. > >>>>>>>>> "MUST" keyword must belong to the normative section. > >>>>>>>> Okay. Thanks for pointing out. > >>>>>>>> > >>>>>>>>>> + > >>>>>>>>>> +The device calculates the hash on GRE-encapsulated packets whose inner payloads > >>>>>>>>>> +are IPv4 packets according to 'Enabled hash types' bitmasks as follows: > >>>>>>>>>> +\begin{itemize} > >>>>>>>>>> + \item If both VIRTIO_NET_HASH_TYPE_GRE_INNER and VIRTIO_NET_HASH_TYPE_TCPv4 bits > >>>>>>>>>> + are set, and the GRE-encapsulated packet has an inner TCPv4 header in its > >>>>>>>>>> + payload, the hash is calculated over the following fields: > >>>>>>>>>> + \begin{itemsize} > >>>>>>>>>> + \item Inner source IP address > >>>>>>>>>> + \item Inner destination IP address > >>>>>>>>>> + \item Inner source TCP port > >>>>>>>>>> + \item Inner destination TCP port > >>>>>>>>>> + \end{itemsize} > >>>>>>>>>> + \item Else if both VIRTIO_NET_HASH_TYPE_GRE_INNER and VIRTIO_NET_HASH_TYPE_UDPv4 > >>>>>>>>>> + bits are set, and the GRE-encapsulated packet has an inner UDPv4 header in > >>>>>>>>>> + its payload, the hash is calculated over the following fields: > >>>>>>>>>> + \begin{itemsize} > >>>>>>>>>> + \item Inner source IP address > >>>>>>>>>> + \item Inner destination IP address > >>>>>>>>>> + \item Inner source UDP port > >>>>>>>>>> + \item Inner destination UDP port > >>>>>>>>>> + \end{itemize} > >>>>>>>>>> + \item Else if both VIRTIO_NET_HASH_TYPE_GRE_INNER and VIRTIO_NET_HASH_TYPE_IPv4 > >>>>>>>>>> + bits are set, the hash is calculated over the following fields: > >>>>>>>>>> + \begin{itemsize} > >>>>>>>>>> + \item Inner source IP address > >>>>>>>>>> + \item Inner destination IP address > >>>>>>>>>> + \end{itemsize} > >>>>>>>>>> + \item Else the device does not calculate the hash > >>>>>>>>>> +\end{itemize} > >>>>>>>>>> + > >>>>>>>>>> +The device calculates the hash on GRE-encapsulated packets whose inner payloads > >>>>>>>>>> +are IPv6 packets without extension headers according to 'Enabled hash types' > >>>>>>>>>> +bitmasks as follows: > >>>>>>>>>> +\begin{itemsize} > >>>>>>>>>> + \item If both VIRTIO_NET_HASH_TYPE_GRE_INNER and VIRTIO_NET_HASH_TYPE_TCPv6 > >>>>>>>>>> + bits are set, and the GRE-encapsulated packet has an inner TCPv6 header in > >>>>>>>>>> + its payload, the hash is calculated over the following fields: > >>>>>>>>>> + \begin{itemsize} > >>>>>>>>>> + \item Inner source IPv6 address > >>>>>>>>>> + \item Inner destination IPv6 address > >>>>>>>>>> + \item Inner source TCP port > >>>>>>>>>> + \item Inner destination TCP port > >>>>>>>>>> + \end{itemsize} > >>>>>>>>>> + \item Else if both VIRTIO_NET_HASH_TYPE_GRE_INNER and VIRTIO_NET_HASH_TYPE_UDPv6 > >>>>>>>>>> + bits are set, and the GRE-encapsulated packet has an inner UDPv6 header in > >>>>>>>>>> + its payload, the hash is calculated over the following fields: > >>>>>>>>>> + \begin{itemsize} > >>>>>>>>>> + \item Inner source IPv6 address > >>>>>>>>>> + \item Inner destination IPv6 address > >>>>>>>>>> + \item Inner source UDP port > >>>>>>>>>> + \item Inner destination UDP port > >>>>>>>>>> + \end{itemize} > >>>>>>>>>> + \item Else if both VIRTIO_NET_HASH_TYPE_GRE_INNER and VIRTIO_NET_HASH_TYPE_IPv6 > >>>>>>>>>> + bits are set, the hash is calculated over the following fields: > >>>>>>>>>> + \begin{itemsize} > >>>>>>>>>> + \item Inner source IPv6 address > >>>>>>>>>> + \item Inner destination IPv6 address > >>>>>>>>>> + \end{itemsize} > >>>>>>>>>> + \item Else the device does not calculate the hash > >>>>>>>>>> +\end{itemize} > >>>>>>>>>> + > >>>>>>>>>> +The device calculates the hash on GRE-encapsulated packets whose inner payloads > >>>>>>>>>> +are IPv6 packets with extension headers according to 'Enabled hash types' > >>>>>>>>>> +bitmasks as follows: > >>>>>>>>>> +\begin{itemsize} > >>>>>>>>>> + \item If both VIRTIO_NET_HASH_TYPE_GRE_INNER and VIRTIO_NET_HASH_TYPE_TCP_EX > >>>>>>>>>> + bits are set, and the GRE-encapsulated packet has an inner TCPv6 header in > >>>>>>>>>> + its payload, the hash is calculated over the following fields: > >>>>>>>>>> + \begin{itemize} > >>>>>>>>>> + \item Home address from the home address option in the IPv6 destination options > >>>>>>>>> Is this inner or outer? > >>>>>>>>> > >>>>>>>>> Thanks > >>>>>>>>> > >>>>>>>>>> + 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 both VIRTIO_NET_HASH_TYPE_GRE_INNER and VIRTIO_NET_HASH_TYPE_UDP_EX > >>>>>>>>>> + bits are set, and the GRE-encapsulated packet has an inner UDPv6 header in its > >>>>>>>>>> + payload, the hash is calculated over the following fields: > >>>>>>>>>> + \begin{itemsize} > >>>>>>>>>> + \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 both VIRTIO_NET_HASH_TYPE_GRE_INNER and VIRTIO_NET_HASH_TYPE_IP_EX > >>>>>>>>>> + bits are set, the hash is calculated over the following fields: > >>>>>>>>>> + \begin{itemsize} > >>>>>>>>>> + \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 > >>>>>>>>>> + a GRE-encapsulated packet whose inner payload is an IPv6 packet without > >>>>>>>>>> + extension headers > >>>>>>>>>> +\end{itemsize} > >>>>>>>>>> + > >>>>>>>>>> \paragraph{Hash reporting for incoming packets} > >>>>>>>>>> \label{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets / Hash reporting for incoming packets} > >>>>>>>>>> > >>>>>>>>>> @@ -4005,6 +4117,10 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network > >>>>>>>>>> #define VIRTIO_NET_HASH_REPORT_UDPv6_EX 9 > >>>>>>>>>> \end{lstlisting} > >>>>>>>>>> > >>>>>>>>>> +VIRTIO_NET_HASH_TYPE_GRE_INNER bit is not included in \field{hash_report}, > >>>>>>>>>> +it just indicates that the hash is calculated using the inner header inside > >>>>>>>>>> +the GRE-encapsulated packet. > >>>>>>>>>> + > >>>>>>>>>> \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 > >>>>>>>>>> -- > >>>>>>>>>> 2.19.1.6.gb485710b > >>>>>>>>>> > >>>>>>>> --------------------------------------------------------------------- > >>>>>>>> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org > >>>>>>>> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org > >>>>>>>> > >>>>>> --------------------------------------------------------------------- > >>>>>> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org > >>>>>> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org > >>>>>> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]