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

[Parav Pandit <parav@nvidia.com>]

> From: Satananda Burla <sburla@marvell.com>
> Sent: Monday, October 30, 2023 7:06 AM
> 
> 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=NHDPsfcAYl
> N2z-
> >
> NXHHG4WB09qqS0voo_nf6_kGS625A&m=GknvLw2Qpf9nPonjhWw3_Lc5eykfV
> dDRg1fga_
> > 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 ?
In practice, mostly not so many. But kept the space in case.
Currently around 200+ ether types are defined at [1].
[1] https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml

> > +\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?

IPv4 is at 0x200
IPV6 is at 0x300
L4 is at 0x400.

So there is space reserved for 256 for each L3 type.

Do you mean to leave less bits than worth of 256?

> Specifically for IPV6 we may need extension header bits matching in future. (SPI
> in ESP extension header for instance).
Yes, above reserved space can fit IPv6 extension starting 0x301 to 0x3ff.

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