From: Heng Qi <hengqi@linux.alibaba.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtio-dev@lists.oasis-open.org,
virtio-comment@lists.oasis-open.org, jasowang@redhat.com,
parav@nvidia.com, xuanzhuo@linux.alibaba.com
Subject: Re: [virtio-comment] Re: [PATCH] virtio-net: support the outer source port hash for UDP-encapsulated packets
Date: Tue, 8 Aug 2023 10:42:07 +0800 [thread overview]
Message-ID: <20230808024207.GC11361@h68b04307.sqa.eu95> (raw)
In-Reply-To: <20230807104317-mutt-send-email-mst@kernel.org>
On Mon, Aug 07, 2023 at 10:56:41AM -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 28, 2023 at 04:46:35PM +0800, Heng Qi wrote:
> > UDP tunneling protocols usually identify a flow using the outer source UDP
> > port, which is useful for processing UDP-encapsulated packets, such as
> > increasing entropy for RSS queue selection or hashing the same flow to the
> > same receive queue. Therefore, we extend it as a new RSS configuration.
> >
>
> that's not a real motivation is it? it's already included for
> increasing entropy.
>
> the real motivation is ignoring source and destination ip
> because they can change if tunneling gateway changes, right?
Yes, I will rewrite the commit log with your comments.
>
>
> > Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> > Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > ---
> > device-types/net/description.tex | 49 ++++++++++++++++++++++++-
> > device-types/net/device-conformance.tex | 1 +
> > 2 files changed, 48 insertions(+), 2 deletions(-)
> >
> > diff --git a/device-types/net/description.tex b/device-types/net/description.tex
> > index 76585b0..366775a 100644
> > --- a/device-types/net/description.tex
> > +++ b/device-types/net/description.tex
> > @@ -88,6 +88,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_UDP_TUNNEL_SRCPORT(50)] Device supports outer source port hash
> > + for UDP-encapsulated packets.
> > +
> > \item[VIRTIO_NET_F_HASH_TUNNEL(51)] Device supports inner header hash for encapsulated packets.
> >
> > \item[VIRTIO_NET_F_VQ_NOTF_COAL(52)] Device supports virtqueue notification coalescing.
> > @@ -150,6 +153,7 @@ \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device
> > \item[VIRTIO_NET_F_RSS] Requires VIRTIO_NET_F_CTRL_VQ.
> > \item[VIRTIO_NET_F_VQ_NOTF_COAL] Requires VIRTIO_NET_F_CTRL_VQ.
> > \item[VIRTIO_NET_F_HASH_TUNNEL] Requires VIRTIO_NET_F_CTRL_VQ along with VIRTIO_NET_F_RSS or VIRTIO_NET_F_HASH_REPORT.
> > +\item[VIRTIO_NET_F_HASH_UDP_TUNNEL_SRCPORT] Requires VIRTIO_NET_F_CTRL_VQ along with VIRTIO_NET_F_RSS 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}
> > @@ -927,11 +931,29 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
> > #define VIRTIO_NET_HASH_TYPE_UDP_EX (1 << 8)
> > \end{lstlisting}
> >
> > +A UDP-encapsulated packet uses UDP as the transport protocol in the outer header
> > +\ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets / Hash calculation for incoming packets / Encapsulated packet}.
> > +UDP tunneling protocols usually use the outer source UDP port to identify a specific flow.
> > +The hash calculated over the outer source UDP port
> > can thus be used by the device to queue these different flows
>
> what does this "can be used" mean here is unclear.
For example, "can be used" when the same flow traverses different
tunnels and has different outer source IPs.
>
> > +on different receive queues or queue the same specific flow on the same receive queue.
>
> different from what? same as what?
different flows -> different queues, not different from something.
I'll rewrite this paragraph for more clarity.
>
>
> > +
> > +If additionally the feature VIRTIO_NET_F_HASH_UDP_TUNNEL_SRCPORT was negotiated,
> > +the following hash types are applicable for UDP-encapsulated packets:
> > +\begin{lstlisting}
> > +#define VIRTIO_NET_HASH_TYPE_UDPv4_TUNNEL_SRCPORT (1 << 9)
> > +#define VIRTIO_NET_HASH_TYPE_UDPv6_TUNNEL_SRCPORT (1 << 10)
> > +\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
> > +\item If additionally VIRTIO_NET_HASH_TYPE_UDPv4_TUNNEL_SRCPORT is set and a received encapsulated
>
> what makes the packet "encapsulated" here is unclear.
UDP tunneling protocols makes the packet "encapsulated".
Will modify in the next version.
Thanks!
>
> > +packet has an outer UDPv4 header, the hash is calculated over the following fields:
> > +\begin{itemize}
> > +\item Outer source UDP port
> > +\end{itemize}
> > +\item Else 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
> > @@ -961,7 +983,12 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
> > 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
> > +\item If additionally VIRTIO_NET_HASH_TYPE_UDPv6_TUNNEL_SRCPORT is set and a received encapsulated
> > +packet has an outer UDPv6 header, the hash is calculated over the following fields:
> > +\begin{itemize}
> > +\item Outer source UDP port
> > +\end{itemize}
> > +\item Else 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
> > @@ -991,6 +1018,11 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
> > The device calculates the hash on IPv6 packets with extension
> > headers according to 'Enabled hash types' bitmask as follows:
> > \begin{itemize}
> > +\item If additionally VIRTIO_NET_HASH_TYPE_UDPv6_TUNNEL_SRCPORT is set and a received encapsulated
> > +packet has an outer UDPv6 header, the hash is calculated over the following fields:
> > +\begin{itemize}
> > +\item Outer source UDP port
> > +\end{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}
> > @@ -1139,8 +1171,21 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
> > #define VIRTIO_NET_HASH_REPORT_IPv6_EX 7
> > #define VIRTIO_NET_HASH_REPORT_TCPv6_EX 8
> > #define VIRTIO_NET_HASH_REPORT_UDPv6_EX 9
> > +#define VIRTIO_NET_HASH_REPORT_UDPv4_TUNNEL_SRCPORT 10 /* Only if additionally VIRTIO_NET_F_HASH_UDP_TUNNEL_SRCPORT was negotiated */
> > +#define VIRTIO_NET_HASH_REPORT_UDPv6_TUNNEL_SRCPORT 11 /* Only if additionally VIRTIO_NET_F_HASH_UDP_TUNNEL_SRCPORT was negotiated */
> > \end{lstlisting}
> >
> > +\devicenormative{\subparagraph}{Outer Source UDP Port}{Device Types / Network Device / Device Operation / Outer Source UDP Port}
> > +
> > +When all the following cases occur:
> > +\begin{itemize}
> > +\item Both VIRTIO_NET_F_HASH_UDP_TUNNEL_SRCPORT and VIRTIO_NET_F_HASH_TUNNEL are negotiated.
> > +\item A received UDP-encapsulated packet's outer header matches one of the encapsulation types enabled in \field{enabled_tunnel_types}.
> > +\item VIRTIO_NET_HASH_TYPE_UDPv4_TUNNEL_SRCPORT is set in \field{hash_types} and a received encapsulated packet has an outer UDPv4 header or
> > + VIRTIO_NET_HASH_TYPE_UDPv6_TUNNEL_SRCPORT is set in \field{hash_types} and a received encapsulated packet has an outer UDPv6 header.
> > +\end{itemize}
> > +the device MUST calculate the hash over the inner header rather than the outer source UDP port.
> > +
> > \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
> > diff --git a/device-types/net/device-conformance.tex b/device-types/net/device-conformance.tex
> > index f88f48b..4fd036b 100644
> > --- a/device-types/net/device-conformance.tex
> > +++ b/device-types/net/device-conformance.tex
> > @@ -7,6 +7,7 @@
> > \item \ref{devicenormative:Device Types / Network Device / Device Operation / Packet Transmission}
> > \item \ref{devicenormative:Device Types / Network Device / Device Operation / Setting Up Receive Buffers}
> > \item \ref{devicenormative:Device Types / Network Device / Device Operation / Processing of Incoming Packets}
> > +\item \ref{devicenormative:Device Types / Network Device / Device Operation / Outer Source UDP Port}
> > \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Packet Receive Filtering}
> > \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / Setting MAC Address Filtering}
> > \item \ref{devicenormative:Device Types / Network Device / Device Operation / Control Virtqueue / VLAN Filtering}
> > --
> > 2.19.1.6.gb485710b
>
>
> 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/
prev parent reply other threads:[~2023-08-08 2:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-28 8:46 [virtio-comment] [PATCH] virtio-net: support the outer source port hash for UDP-encapsulated packets Heng Qi
2023-07-28 8:53 ` Heng Qi
2023-08-07 7:34 ` [virtio-comment] Re: [virtio-dev] " Heng Qi
2023-08-07 14:56 ` [virtio-comment] " Michael S. Tsirkin
2023-08-08 2:42 ` Heng Qi [this message]
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=20230808024207.GC11361@h68b04307.sqa.eu95 \
--to=hengqi@linux.alibaba.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=parav@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=xuanzhuo@linux.alibaba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).