From: Parav Pandit <parav@nvidia.com>
To: Satananda Burla <sburla@marvell.com>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
"mst@redhat.com" <mst@redhat.com>,
"cohuck@redhat.com" <cohuck@redhat.com>
Cc: Shahaf Shuler <shahafs@nvidia.com>,
"si-wei.liu@oracle.com" <si-wei.liu@oracle.com>,
"xuanzhuo@linux.alibaba.com" <xuanzhuo@linux.alibaba.com>,
Heng Qi <hengqi@linux.alibaba.com>
Subject: [virtio-comment] RE: [EXT] [PATCH v3 2/6] virtio-net: Add flow filter capabilities read commands
Date: Mon, 30 Oct 2023 03:33:12 +0000 [thread overview]
Message-ID: <PH0PR12MB54816AB3EAB426A5AC8FC0BCDCA1A@PH0PR12MB5481.namprd12.prod.outlook.com> (raw)
In-Reply-To: <SJ0PR18MB447748C4B448023563A7F6DBC3A1A@SJ0PR18MB4477.namprd18.prod.outlook.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
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/
next prev parent reply other threads:[~2023-10-30 3:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20231027132324.1349963-1-parav@nvidia.com>
[not found] ` <20231027132324.1349963-3-parav@nvidia.com>
2023-10-30 1:36 ` [virtio-comment] RE: [EXT] [PATCH v3 2/6] virtio-net: Add flow filter capabilities read commands Satananda Burla
2023-10-30 3:33 ` Parav Pandit [this message]
[not found] ` <20231027132324.1349963-6-parav@nvidia.com>
2023-10-30 1:36 ` [virtio-comment] RE: [EXT] [PATCH v3 5/6] virtio-net: Add flow filter match entry, action and requests Satananda Burla
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=PH0PR12MB54816AB3EAB426A5AC8FC0BCDCA1A@PH0PR12MB5481.namprd12.prod.outlook.com \
--to=parav@nvidia.com \
--cc=cohuck@redhat.com \
--cc=hengqi@linux.alibaba.com \
--cc=mst@redhat.com \
--cc=sburla@marvell.com \
--cc=shahafs@nvidia.com \
--cc=si-wei.liu@oracle.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=xuanzhuo@linux.alibaba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).