RE: [EXT] [PATCH v3 2/6] virtio-net: Add flow filter capabilities read commands

[Satananda Burla <sburla@marvell.com>]

Hi Parav

> -----Original Message-----
> From: Parav Pandit <parav@nvidia.com>
> Sent: Friday, October 27, 2023 6:23 AM
> To: virtio-comment@lists.oasis-open.org; mst@redhat.com;
> cohuck@redhat.com
> Cc: Satananda Burla <sburla@marvell.com>; shahafs@nvidia.com; si-
> wei.liu@oracle.com; xuanzhuo@linux.alibaba.com; Parav Pandit
> <parav@nvidia.com>; Heng Qi <hengqi@linux.alibaba.com>
> Subject: [EXT] [PATCH v3 2/6] virtio-net: Add flow filter capabilities
> read commands
> 
> External Email
> 
> ----------------------------------------------------------------------
> The device responds flow filter capabilities using two commands.
> One command indicates generic flow filter device limits such as
> number of flow filters, number of flow filter groups, support or
> multiple transports etc.
> 
> The second command indicates supported match types, and fields
> of the packet.
> 
> Fixes: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_oasis-2Dtcs_virtio-
> 2Dspec_issues_179&d=DwIDAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=NHDPsfcAYlN2z-
> NXHHG4WB09qqS0voo_nf6_kGS625A&m=GknvLw2Qpf9nPonjhWw3_Lc5eykfVdDRg1fga_EJ
> CtMR5FPF3CjtDKJYjCUT1tvU&s=XW811-B24-
> DCa7KJgZdBUlXx9LYmZMzfByaCAlChmi8&e=
> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> Signed-off-by: Parav Pandit <parav@nvidia.com>
> 
> ---
> changelog:
> v1->v2:
> - addressed comments from Satananda
> - added vlan type match field
> - kept space for types between l2, l3, l4 header match types
> - renamed mask to mask_supported with shorter width
> - made more fields reserved for furture
> - addressed comments from Heng
> - grammar correction
> - added field to indicate supported number of actions per flow
>   filter match entry
> - added missing documentation for max_flow_priorities_per_group
> v0->v1:
> - added mask field in the type to indicate supported mask by device
>   and also in later patch to use it to indicate mask on adding
>   flow filter. As a result removed the mask_supported capability
>   field
> ---
>  device-types/net/description.tex | 220 ++++++++++++++++++++++++++++++-
>  1 file changed, 218 insertions(+), 2 deletions(-)
> 
> diff --git a/device-types/net/description.tex b/device-
> types/net/description.tex
> index fc56af6..2aba5d0 100644
> --- a/device-types/net/description.tex
> +++ b/device-types/net/description.tex
> @@ -1173,7 +1173,11 @@ \subsubsection{Flow Filter}\label{sec:Device
> Types / Network Device / Device Ope
>  The device indicates the flow filter capabilities to the driver. These
>  capabilities include various maximum device limits, supported
> transports and
>  supported packet match fields. The driver enables the transport for
> flow
> -filter requests using a control virtqueue command.
> +filter requests using a control virtqueue command. These control
> virtqueue
> +commands are:
> +\ref{sec:Device Types / Network Device / Device Operation / Control
> Virtqueue / Flow Filter / Flow Filter Capabilities Get}
> +and
> +\ref{sec:Device Types / Network Device / Device Operation / Control
> Virtqueue / Flow Filter / Flow Filter Match Capabilities Get}.
> 
>  The device supports transporting flow filter requests on either the
> control
>  virtqueue or on the flow filter virtqueues or on both. However, device
> @@ -1181,6 +1185,8 @@ \subsubsection{Flow Filter}\label{sec:Device Types
> / Network Device / Device Ope
>  at a time, i.e. either control virtqueue or flow filter virtqueues.
>  Once the driver sets the flow filter request transport in the device,
>  the driver can send flow filter request using the enabled transport.
> +The driver enables the transport for flow filter requests using a
> control
> +virtqueue command.
> 
>  The flow filters are grouped using a flow filter group. Each flow
> filter
>  group has a priority. The device first applies the flow filters of the
> highest
> @@ -1247,7 +1253,136 @@ \subsubsection{Flow Filter}\label{sec:Device
> Types / Network Device / Device Ope
>        the flow filters in group_C, the flow filters of next level
> group_B are applied.
>  \end{itemize}
> 
> -\label{sec:Device Types / Network Device / Device Operation / Control
> Virtqueue / Setting Promiscuous Mode}%old label for latexdiff
> +\paragraph{Match Types and Fields}\label{sec:Device Types / Network
> Device / Device Operation / Flow Filter / Match Types and Fields}
> +
> +\begin{lstlisting}
> +struct virtio_net_ff_match_type_cap {
> +        le16 type;
> +        u8 mask_supported;
> +        u8 reserved[5];
> +        le64 fields_bmap;
> +};
> +\end{lstlisting}
> +
> +The \field{type} corresponds to following table:
> +
> +\begin{tabular}{|l|l|l|}
> +\hline
> +Type & Name & Description \\
> +\hline \hline
> +0   & VIRTIO_NET_FF_ETH_HDR & Ethernet header of the packet \\
> +\hline
> +0x1   & VIRTIO_NET_FF_VLAN_TAG_HDR & VLAN tag of the packet \\
> +\hline
> +0x200   & VIRTIO_NET_FF_IPV4_HDR & IPv4 header of the packet \\
This leaves 256 types for L2 and VLAN, do we really need
so many L2 types ?
> +\hline
> +0x300   & VIRTIO_NET_FF_IPV6_HDR & IPv6 header of the packet \\
> +\hline
Can we leave a few bits (4) for L3 headers and start L4 after?
Specifically for IPV6 we may need extension header bits matching in
future. (SPI in ESP extension header for instance). 
> +0x400   & VIRTIO_NET_FF_TCP_HDR & TCP header of the packet \\
> +\hline
> +0x500   & VIRTIO_NET_FF_UDP_HDR & UDP header of the packet \\
 
Regards
Satananda