From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Heng Qi <hengqi@linux.alibaba.com>,
virtio-dev@lists.oasis-open.org,
virtio-comment@lists.oasis-open.org,
Jason Wang <jasowang@redhat.com>,
Yuri Benditovich <yuri.benditovich@daynix.com>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Subject: Re: [virtio-comment] Re: [PATCH v13] virtio-net: support inner header hash
Date: Tue, 25 Apr 2023 17:06:24 -0400 [thread overview]
Message-ID: <20230425170341-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <f9221063-8419-9cb3-e59c-0b0393bdd501@nvidia.com>
On Tue, Apr 25, 2023 at 04:28:33PM -0400, Parav Pandit wrote:
>
>
> On 4/23/2023 3:35 AM, Heng Qi wrote:
> > \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;
this needs a comment explaining it only exists with some
feature bits.
> > };
> In v12 I was asking this to move to above field from the config area to the
> GET command in comment [1] as,
>
> "With that no need to define two fields at two different places in config
> area and also in cvq."
I think I disagree.
the proposed design is consistent with regular tunneling.
however I feel we should limit this to 1-2 legacy protocols.
with that, we do not really need a new field at all,
they can fit in supported_hash_types.
> I am sorry if that was not clear enough.
>
> [1] https://lore.kernel.org/virtio-dev/569cbaf9-f1fb-0e1f-a2ef-b1d7cd7dbb1f@nvidia.com/
>
> > \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}
> > +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 +993,152 @@ \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}
> > +\paragraph{Inner Header Hash}
> > +\label{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets / Inner Header Hash}
> > +
> > +If VIRTIO_NET_F_HASH_TUNNEL has been negotiated, the device supports inner header hash and the driver can send
> > +commands VIRTIO_NET_CTRL_TUNNEL_HASH_SET and VIRTIO_NET_CTRL_TUNNEL_HASH_GET for the inner header hash configuration.
> > +
> > +struct virtio_net_hash_tunnel_config {
> Please move field from the config struct to here. Both are RO fields.
>
> le32 supported_hash_tunnel_types;
> > + le32 hash_tunnel_types;
> > +};
> > +
> > +#define VIRTIO_NET_CTRL_TUNNEL_HASH 7
> > + #define VIRTIO_NET_CTRL_TUNNEL_HASH_SET 0
> > + #define VIRTIO_NET_CTRL_TUNNEL_HASH_GET 1
> > +
> > +Filed \field{hash_tunnel_types} contains a bitmask of configured hash tunnel types as
> > +defined in \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets / Hash calculation for incoming packets / Supported/enabled hash tunnel types}.
> > +
> > +The class VIRTIO_NET_CTRL_TUNNEL_HASH has the following commands:
> > +\begin{itemize}
> > +\item VIRTIO_NET_CTRL_TUNNEL_HASH_SET: set the \field{hash_tunnel_types} to configure the inner header hash calculation for the device.
> > +\item VIRTIO_NET_CTRL_TUNNEL_HASH_GET: get the \field{hash_tunnel_types} from the device.
> > +\end{itemize}
> > +
> > +For the command VIRTIO_NET_CTRL_TUNNEL_HASH_SET, the structure virtio_net_hash_tunnel_config is write-only for the driver.
> > +For the command VIRTIO_NET_CTRL_TUNNEL_HASH_GET, the structure virtio_net_hash_tunnel_config is read-only for the driver.
> > +
> You need to split the structures to two, one for get and one for set in
> above description as get and set contains different fields.
> > +
> > +If VIRTIO_NET_HASH_TUNNEL_TYPE_NONE is set or the encapsulation type is not included in \field{hash_tunnel_types},
> > +the hash of the outer header is calculated for the received encapsulated packet.
> > +
> > +
> > +For scenarios with sufficient external entropy or no internal hashing requirements, inner header hash may not be needed:
> > +A tunnel is often expected to isolate the external network from the internal one. By completely ignoring entropy
> > +in the external header and replacing it with entropy from the internal header, for hash calculations, this expectation
> You wanted to say inner here like rest of the places.
>
> s/internal header/inner header
>
> > +The driver MUST NOT set any VIRTIO_NET_HASH_TUNNEL_TYPE_ flags that are not supported by the device.
> Multiple flags so,
>
> s/flags that are/flags which are/
>
> 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/
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Heng Qi <hengqi@linux.alibaba.com>,
virtio-dev@lists.oasis-open.org,
virtio-comment@lists.oasis-open.org,
Jason Wang <jasowang@redhat.com>,
Yuri Benditovich <yuri.benditovich@daynix.com>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Subject: [virtio-dev] Re: [virtio-comment] Re: [PATCH v13] virtio-net: support inner header hash
Date: Tue, 25 Apr 2023 17:06:24 -0400 [thread overview]
Message-ID: <20230425170341-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <f9221063-8419-9cb3-e59c-0b0393bdd501@nvidia.com>
On Tue, Apr 25, 2023 at 04:28:33PM -0400, Parav Pandit wrote:
>
>
> On 4/23/2023 3:35 AM, Heng Qi wrote:
> > \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;
this needs a comment explaining it only exists with some
feature bits.
> > };
> In v12 I was asking this to move to above field from the config area to the
> GET command in comment [1] as,
>
> "With that no need to define two fields at two different places in config
> area and also in cvq."
I think I disagree.
the proposed design is consistent with regular tunneling.
however I feel we should limit this to 1-2 legacy protocols.
with that, we do not really need a new field at all,
they can fit in supported_hash_types.
> I am sorry if that was not clear enough.
>
> [1] https://lore.kernel.org/virtio-dev/569cbaf9-f1fb-0e1f-a2ef-b1d7cd7dbb1f@nvidia.com/
>
> > \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}
> > +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 +993,152 @@ \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}
> > +\paragraph{Inner Header Hash}
> > +\label{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets / Inner Header Hash}
> > +
> > +If VIRTIO_NET_F_HASH_TUNNEL has been negotiated, the device supports inner header hash and the driver can send
> > +commands VIRTIO_NET_CTRL_TUNNEL_HASH_SET and VIRTIO_NET_CTRL_TUNNEL_HASH_GET for the inner header hash configuration.
> > +
> > +struct virtio_net_hash_tunnel_config {
> Please move field from the config struct to here. Both are RO fields.
>
> le32 supported_hash_tunnel_types;
> > + le32 hash_tunnel_types;
> > +};
> > +
> > +#define VIRTIO_NET_CTRL_TUNNEL_HASH 7
> > + #define VIRTIO_NET_CTRL_TUNNEL_HASH_SET 0
> > + #define VIRTIO_NET_CTRL_TUNNEL_HASH_GET 1
> > +
> > +Filed \field{hash_tunnel_types} contains a bitmask of configured hash tunnel types as
> > +defined in \ref{sec:Device Types / Network Device / Device Operation / Processing of Incoming Packets / Hash calculation for incoming packets / Supported/enabled hash tunnel types}.
> > +
> > +The class VIRTIO_NET_CTRL_TUNNEL_HASH has the following commands:
> > +\begin{itemize}
> > +\item VIRTIO_NET_CTRL_TUNNEL_HASH_SET: set the \field{hash_tunnel_types} to configure the inner header hash calculation for the device.
> > +\item VIRTIO_NET_CTRL_TUNNEL_HASH_GET: get the \field{hash_tunnel_types} from the device.
> > +\end{itemize}
> > +
> > +For the command VIRTIO_NET_CTRL_TUNNEL_HASH_SET, the structure virtio_net_hash_tunnel_config is write-only for the driver.
> > +For the command VIRTIO_NET_CTRL_TUNNEL_HASH_GET, the structure virtio_net_hash_tunnel_config is read-only for the driver.
> > +
> You need to split the structures to two, one for get and one for set in
> above description as get and set contains different fields.
> > +
> > +If VIRTIO_NET_HASH_TUNNEL_TYPE_NONE is set or the encapsulation type is not included in \field{hash_tunnel_types},
> > +the hash of the outer header is calculated for the received encapsulated packet.
> > +
> > +
> > +For scenarios with sufficient external entropy or no internal hashing requirements, inner header hash may not be needed:
> > +A tunnel is often expected to isolate the external network from the internal one. By completely ignoring entropy
> > +in the external header and replacing it with entropy from the internal header, for hash calculations, this expectation
> You wanted to say inner here like rest of the places.
>
> s/internal header/inner header
>
> > +The driver MUST NOT set any VIRTIO_NET_HASH_TUNNEL_TYPE_ flags that are not supported by the device.
> Multiple flags so,
>
> s/flags that are/flags which are/
>
> 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/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2023-04-25 21:06 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-23 7:35 [virtio-comment] [PATCH v13] virtio-net: support inner header hash Heng Qi
2023-04-23 7:35 ` [virtio-dev] " Heng Qi
2023-04-25 20:28 ` [virtio-comment] " Parav Pandit
2023-04-25 20:28 ` [virtio-dev] " Parav Pandit
2023-04-25 21:06 ` Michael S. Tsirkin [this message]
2023-04-25 21:06 ` [virtio-dev] Re: [virtio-comment] " Michael S. Tsirkin
2023-04-25 21:39 ` Parav Pandit
2023-04-25 21:39 ` [virtio-dev] " Parav Pandit
2023-04-26 4:12 ` Michael S. Tsirkin
2023-04-26 4:12 ` [virtio-dev] " Michael S. Tsirkin
2023-04-26 4:27 ` Parav Pandit
2023-04-26 4:27 ` [virtio-dev] " Parav Pandit
2023-04-26 5:02 ` Michael S. Tsirkin
2023-04-26 5:02 ` [virtio-dev] " Michael S. Tsirkin
2023-04-26 13:42 ` Heng Qi
2023-04-26 13:42 ` [virtio-dev] " Heng Qi
2023-04-26 13:47 ` [virtio-comment] " Parav Pandit
2023-04-26 13:47 ` [virtio-dev] " Parav Pandit
2023-04-26 14:03 ` [virtio-comment] " Heng Qi
2023-04-26 14:03 ` [virtio-dev] " Heng Qi
2023-04-26 14:24 ` Parav Pandit
2023-04-26 14:24 ` [virtio-dev] " Parav Pandit
2023-04-26 14:57 ` Michael S. Tsirkin
2023-04-26 14:57 ` [virtio-dev] " Michael S. Tsirkin
2023-04-26 15:20 ` Parav Pandit
2023-04-26 15:20 ` [virtio-dev] " Parav Pandit
2023-04-27 2:19 ` [virtio-comment] " Heng Qi
2023-04-27 2:19 ` Heng Qi
2023-04-25 21:03 ` [virtio-comment] " Michael S. Tsirkin
2023-04-25 21:03 ` [virtio-dev] " Michael S. Tsirkin
2023-04-26 14:14 ` Heng Qi
2023-04-26 14:14 ` [virtio-dev] " Heng Qi
2023-04-26 14:48 ` Michael S. Tsirkin
2023-04-26 14:48 ` [virtio-dev] " Michael S. Tsirkin
2023-04-27 2:28 ` [virtio-comment] " Heng Qi
2023-04-27 2:28 ` Heng Qi
2023-04-27 17:13 ` [virtio-comment] " Michael S. Tsirkin
2023-04-27 17:13 ` Michael S. Tsirkin
2023-05-05 13:51 ` [virtio-comment] " Heng Qi
2023-05-05 13:51 ` [virtio-dev] " Heng Qi
2023-05-05 14:56 ` Michael S. Tsirkin
2023-05-05 14:56 ` [virtio-dev] " Michael S. Tsirkin
2023-05-09 14:22 ` [virtio-comment] " Heng Qi
2023-05-09 14:22 ` Heng Qi
2023-05-09 15:15 ` [virtio-comment] " Michael S. Tsirkin
2023-05-09 15:15 ` Michael S. Tsirkin
2023-05-10 9:15 ` [virtio-comment] " Heng Qi
2023-05-10 9:15 ` [virtio-dev] " Heng Qi
2023-05-11 6:22 ` Michael S. Tsirkin
2023-05-11 6:22 ` [virtio-dev] " Michael S. Tsirkin
2023-05-12 6:00 ` Heng Qi
2023-05-12 6:00 ` [virtio-dev] " Heng Qi
2023-05-12 6:54 ` Michael S. Tsirkin
2023-05-12 6:54 ` [virtio-dev] " Michael S. Tsirkin
2023-05-12 7:23 ` Heng Qi
2023-05-12 7:23 ` [virtio-dev] " Heng Qi
2023-05-12 11:27 ` Michael S. Tsirkin
2023-05-12 11:27 ` [virtio-dev] " Michael S. Tsirkin
2023-05-15 6:51 ` Heng Qi
2023-05-15 6:51 ` [virtio-dev] " Heng Qi
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=20230425170341-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=hengqi@linux.alibaba.com \
--cc=jasowang@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 \
--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.