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

[Parav Pandit <parav@nvidia.com>]

> From: Satananda Burla <sburla@marvell.com>
> Sent: Sunday, October 1, 2023 3:12 PM
> 
> Hi Parav,
> 
> > -----Original Message-----
> > From: Parav Pandit <parav@nvidia.com>
> > Sent: Friday, September 22, 2023 6:49 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 2/7] 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=VZgMfa4Q2vc_6OSqt-
> >
> i7ptCKmBnBVtPWeB8zGHF4AuU0LWpisRhRLj4K4W3GE8VX&s=CxdwZkCbr1ldzL
> QMEVrv4
> > F0Bc
> > euW1z-y9HJ4uYkYGiQ&e=
> > Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> > Signed-off-by: Parav Pandit <parav@nvidia.com>
> > ---
> >  device-types/net/description.tex | 194
> > ++++++++++++++++++++++++++++++-
> >  1 file changed, 192 insertions(+), 2 deletions(-)
> >
> > diff --git a/device-types/net/description.tex b/device-
> > types/net/description.tex index c9a8c52..bf6d4c5 100644
> > --- a/device-types/net/description.tex
> > +++ b/device-types/net/description.tex
> > @@ -1168,7 +1168,11 @@ \subsubsection{Flow Filter}\label{sec:Device
> > Types / Network Device / Device Ope  The device indicates the flow
> > filter capabilities to the driver, which  includes 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 support transporting flow filter requests on either the
> > control  virtqueue or on the flow filter virtqueues or on both.
> > However, device @@ -1252,7 +1256,111 @@ \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 {
> > +        le32 type;
> > +        le32 reserved;
> > +        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
> How about vlan?
> > +1   & VIRTIO_NET_FF_IPV4_HDR & IPv4 header of the packet \\
> > +\hline
> > +2   & VIRTIO_NET_FF_IPV6_HDR & IPv6 header of the packet \\
> > +\hline
> > +3   & VIRTIO_NET_FF_TCP_HDR & TCP header of the packet \\
> > +\hline
> > +4   & VIRTIO_NET_FF_UDP_HDR & UDP header of the packet \\
> > +\hline
> > +other   & -    & reserved  \\
> > +\hline
> > +\end{tabular}
> > +
> > +For the \field{type} of VIRTIO_NET_FF_ETH_HDR, header fields are
> > +represented by a bitmap in \field{fields_bmap} are following:
> > +
> > +\begin{tabular}{|l|l|l|}
> > +\hline
> > +Bit & Name & Description \\
> > +\hline \hline
> > +0   & VIRTIO_NET_FF_DST_MAC & Destination MAC address in the packet  \\
> > +\hline
> > +1   & VIRTIO_NET_FF_SRC_MAC & Source MAC address in the packet \\
> > +\hline
> > +2   & VIRTIO_NET_FF_ETHER_TYPE & Ether type in the packet \\
> > +\hline
> > +\end{tabular}
> > +
> > +For the \field{type} of VIRTIO_NET_FF_IPV4_HDR, header fields are
> > +represented by a bitmap in \field{fields_bmap} are following:
> > +
> > +\begin{tabular}{|l|l|l|}
> > +\hline
> > +Bit & Name & Description \\
> > +\hline \hline
> > +0   & VIRTIO_NET_FF_SRC_IPV4 & Source IPV4 address in the packet \\
> > +\hline
> > +1   & VIRTIO_NET_FF_DST_IPV4 & Destination IPV4 address in the packet \\
> > +\hline
> > +other   & -    & reserved  \\
> > +\hline
> > +\end{tabular}
> I think it would be good to indicate the how the fields_bmap can be expanded
> in future for adding additional fields in header.
Yes. I will add an example or a note to indicate this in v1.