Re: [virtio-dev] [PATCH v2 2/2] content: net: steering mode: Add RSS

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Apr 16, 2018 at 04:05:26PM +0300, Sameeh Jubran wrote:
> From: Sameeh Jubran <sjubran@redhat.com>
> 
> This commit introduces the RSS feature into virtio-net. It is introduced
> as a sub mode for a general command which configures the steering mode.
> 
> Most modern high end network devices today support configurable hash functions,
> this commit introduces RSS - Receive Side Scaling - [1] to virtio net device.
> 
> The RSS is a technology from Microsoft that boosts network device performance
> by efficiently distributing the traffic among the CPUs in a multiprocessor
> system.
> 
> This feature is supported in most of the modern network cards as well as most
> modern OSes including Linux and Windows. It is worth mentioning that both DPDK
> and Hyper-v support RSS too.
> 
> [1] https://docs.microsoft.com/en-us/windows-hardware/drivers/network/ndis-receive-side-scaling2
> 
> Signed-off-by: Sameeh Jubran <sjubran@redhat.com>
> ---
>  content.tex | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 114 insertions(+)
> 
> diff --git a/content.tex b/content.tex
> index 3d538e8..8076147 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -4017,6 +4017,7 @@ The device MUST NOT queue packets on receive queues greater than
>  \begin{lstlisting}
>  // steering mode flags
>  #define STEERING_MODE_AUTO          1
> +#define STEERING_MODE_RSS           2
>  
>  struct virtio_net_steering_modes {
>  le32 steering_modes;
> @@ -4027,6 +4028,7 @@ le32 steering_mode;
>  le32 command;
>  
>      union {
> +    struct virtio_net_rss rss_conf;
>      }
>  };
>  
> @@ -4066,6 +4068,118 @@ If this feature has been negotiated, the virtio header has an additional
>  
>  This is the default steering mode, please refer to the "Automatic receive steering in multiqueue" section.
>  
> +\subparagraph{Receive Side Scaling}{Device Types / Network Device / Device Operation / Control Virtqueue / Steering mode / Receive Side Scaling}
> +
> +\begin{lstlisting}
> +#define RSS_HASH_FUNCTION_NONE      1
> +#define RSS_HASH_FUNCTION_TOEPLITZ  2
> +#define RSS_HASH_FUNCTION_SYMMETRIC 3
> +
> +// Hash function fields
> +#define RSS_HASH_FIELDS_IPV4          0x00000100
> +#define RSS_HASH_FIELDS_TCP_IPV4      0x00000200
> +#define RSS_HASH_FIELDS_IPV6          0x00000400
> +#define RSS_HASH_FIELDS_IPV6_EX       0x00000800
> +#define RSS_HASH_FIELDS_TCP_IPV6      0x00001000
> +#define RSS_HASH_FIELDS_TCP_IPV6_EX   0x00002000
> +
> +struct virtio_net_rss_supported_hash{
> +le32 hash_function;
> +}
> +
> +struct virtio_net_rss {
> +le32 hash_function;
> +le32 hash_function_flags;
> +le32 hash_key_length;
> +le32 indirection_table_length;
> +	struct {
> +		le32 hash_key[hash_key_length];
> +		le32 indirection_table[indirection_table_length];
> +	}
> +};
> +
> +#define VIRTIO_NET_SM_CTRL_RSS_GET_SUPPORTED_FUNCTIONS   0
> +#define VIRTIO_NET_SM_CTRL_RSS_SET                       1


Please add comments in the code as well.

> +\end{lstlisting}
> +
> +If the VIRTIO_NET_F_CTRL_STEERING_MODE is negotiated the driver can send control
> +commands for the RSS configuration.

Confused.  Does VIRTIO_NET_F_CTRL_STEERING_MODE imply steering mode
generally or RSS specifically?
How does a device with streering mode ctrl but without RSS look?


> For configuring RSS the virtio_net_steering_mode
> +should be filled. The \field{steering_mode} field should be filled with the STEERING_MODE_RSS
> +flag along with one of the VIRTIO_NET_SM_CTRL_RSS commands in the \field{command} field. The
> +\field{rss_conf} field should be used.
> +
> +The class VIRTIO_NET_CTRL_RSS has two commands:
> +
> +\begin{enumerate}
> +\item VIRTIO_NET_SM_CTRL_RSS_GET_SUPPORTED_FUNCTIONS returns the hash functions
> +	supported by the device to the driver.
> +\item VIRTIO_NET_SM_CTRL_RSS_SET applies the new RSS configuration. The command is
> +	used by the driver for setting RSS hash function, hash key and
> +	indirection table in the device.
> +\end{enumerate}
> +
> +\devicenormative{\subparagraph}{Receive Side Scaling}{Device Types / Network Device / Device Operation / Control Virtqueue / Steering mode / Receive Side Scaling}
> +
> +The device MUST fill the virtio_net_rss_supported_hash structure with the hash
> +functions it supports and return the structure to the driver. Zero or more
> +flags of the RSS_HASH_FUNCTION flags MUST be used to fill the \field{hash_function}
> +field.
> +
> +The device MUST drop all previous RSS configuration upon receiving
> +VIRTIO_NET_SM_CTRL_RSS_SET command.
> +
> +The device MUST set the RSS configuration according to the settings provided as
> +follows, once the configuration process is completed the device SHOULD apply
> +the hash function to each of the incoming packets and distribute the packets
> +through the virqueues using the calculated hash and the indirection table
> +that were earlier provided by the driver.
> +
> +Setting RSS configuration
> +\begin{enumerate}
> +\item The driver fills all of the fields and passes them through the control
> +	queue to the device.
> +
> +\item The device sets the RSS configuration as provided by the driver.
> +
> +\item If the device successfully applied the configuration, on each packet
> +	received the device MUST calculate the hashing for the packet and
> +	store it in the virtio-net header in the \field{hash} field and the
> +	hash fields used in the calculation in rss_hash_type.
> +\end{enumerate}
> +
> +In case of any unexpected values/ unsupported hash function the driver
> +MUST return VIRTIO_NET_ERR in the \field{ack} field.

driver or the device?

All MUST statements belon in correct normative sections.

Generally what is the text trying to say here?

> +
> +\drivernormative{\subparagraph}{Receive Side Scaling}{Device Types / Network Device / Device Operation / Control Virtqueue / Steering mode / Receive Side Scaling}
> +
> +If the driver wants to set RSS hash it should fill the RSS structure fields
> +as follows:
> +
> +\begin{itemize}
> +\item The driver SHOULD choose the hash function that SHOULD be used and fill
> +	it in the \field{hash_function} field along with the appropriate flags
> +	in the \field{hash_function_flags} field. These flags indicate to the
> +	device which packet fields MUST be used in the calculation process of
> +	the hash.
> +\item Once the hash function has been chosen a suitable hash key should be set
> +	in the \field{hash_key} field,

which key is suitable?

> the length of the key should be stored
> +	in the \field{hash_key_length} field.

in 4 byte units?
are there limits on the length?

> +\item Lastly the driver should fill the indirection table array

is an indirection table required? why not have a function produce
the queue number?

> in the
> +	\field{indirection_table} field while setting the array length in
> +	\field{indirection_table_length}.

any limits on the length here?

> This structure is used by the device
> +	for determining in which RX virt queue the packet should be placed.

How?

> +\end{itemize}
> +Once the configuration phase is over successfully, the packets SHOULD have the
> +\field{hash} field with the hash value that was calculated by the device.

Why not make this optional? I suspect it's not really useful e.g. for
dpdk or xdp which do not generally use hardware offloads.

> +
> +Whenever the driver wants to discard the current RSS settings, it can send an
> +VIRTIO_NET_SM_CTRL_RSS_SET command along with rss structure that has
> +RSS_HASH_FUNCTION_NONE the \field{hash_function} field.

And then what happens?

> +
> +The driver MUST check the \field{ack} field value provided by the device, in
> +case the value is not VIRTIO_NET_OK then the driver MUST handle failure and
> +retry another hash function or else give up.

Is there anything special here?

> +
>  \subparagraph{Legacy Interface: Automatic receive steering in multiqueue mode}\label{sec:Device Types / Network Device / Device Operation / Control Virtqueue / Automatic receive steering in multiqueue mode / Legacy Interface: Automatic receive steering in multiqueue mode}
>  When using the legacy interface, transitional devices and drivers
>  MUST format \field{virtqueue_pairs}

conformance statements will need to be updated.

> -- 
> 2.13.6
> 
> 
> ---------------------------------------------------------------------
> 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