From: Parav Pandit <parav@nvidia.com>
To: <virtio-comment@lists.oasis-open.org>, <mst@redhat.com>,
<cohuck@redhat.com>
Cc: <sburla@marvell.com>, <shahafs@nvidia.com>,
<si-wei.liu@oracle.com>, <xuanzhuo@linux.alibaba.com>,
Parav Pandit <parav@nvidia.com>
Subject: [virtio-comment] [PATCH v5 0/5] virtio-net: Support flow filter for receive packets
Date: Thu, 2 Nov 2023 15:28:20 +0200 [thread overview]
Message-ID: <20231102132825.1865068-1-parav@nvidia.com> (raw)
Summary:
========
This series improves virtio net receive packet steering to forward/steer
packets to specific RQ.
This basic functionality will enable Linux ethtool steering, Accelerated
receive flow steering (ARFS) as starting point, and more use cases in
future.
Problem statement:
==================
Currently packet allow/drop interface has few limitations.
1. Driver cannot add or delete an individual entry for mac and vlan.
2. Driver cannot select mac+vlan combination for which
to allow/drop packet.
3. Driver cannot not set other commonly used packet match fields
such as IP header fields, TCP, UDP, SCP header fields.
4. Driver cannot steer specific packets based on the match
fields to specific receiveq.
5. Driver do not have multiple or dedicated virtqueues to
perform flow filter requests in accelerated manner in
the device.
Solution:
=========
Flow filter as a generic framework to overcome above limitations.
Overview:
=========
A flow filter defines the flow based on one or more match fields
of the packet, defines an action like drop/forward to RQ.
The flow filters are organized in flow filter groups so that their
processing can be ordered when multiple applications wants to use it.
Flow filters requests can be transported via control vq or dedicated
flow filter virtqueue so that it does not get intermixed with other
slow operations of cvq.
Flow filter requirements addressed by this series is worked by virtio
community at [1].
Fixes: https://github.com/oasis-tcs/virtio-spec/issues/179
It uses updated control vq command format from [2].
[1] https://lists.oasis-open.org/archives/virtio-comment/202308/msg00263.html
[2] https://lists.oasis-open.org/archives/virtio-comment/202310/msg00047.html
Patch summary:
==============
patch-1 adds theory of operation description for flow filter
patch-2 adds device capabilities cvq commands
patch-3 adds group add/delete commands
patch-4 adds flow filter match key, action and requests to transport via vq
patch-5 adds device and driver requirements
Please review.
Changelog:
==========
v3->v5:
- removed left over dependencies of flow filter virtqueues
- removed partial sentence
v2->v3:
- removed dependency on dynamic queue infrastucture which is
not yet ready
v1->v2:
- addressed comments from Satananda
- squashed with match fields definition patch of v1
- added length to the flexible array definition struct to benefit
from future runtime length bound checkers listed in
https://people.kernel.org/kees/bounded-flexible-arrays-in-c
- renamed value to key
- addressed comments from Satananda
- merged destination and action to one struct
- 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 future
- 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
- fixed comments from Heng
- grammar corrections
- spelling corrections
- fixed spelling from initializaton to initialization
- added more requirements for multiple actions
v0->v1:
- addressed comments from Satananda
- added device requirement to return non zero value in fields_bmap
- added device requirement to not repeat filter type in response
- added driver requirement to order filter match field as it
appears in the packet
- added device requirement to fail group delete command on existing
flow entries
- 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
Parav Pandit (5):
virtio-net: Add theory of operation for flow filter
virtio-net: Add flow filter capabilities read commands
virtio-net: Add flow filter group life cycle commands
virtio-net: Add flow filter match entry, action and requests
virtio-net: Add flow filter device and driver requirements
device-types/net/description.tex | 630 +++++++++++++++++++++++++++++++
1 file changed, 630 insertions(+)
--
2.34.1
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 reply other threads:[~2023-11-02 13:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-02 13:28 Parav Pandit [this message]
2023-11-02 13:28 ` [virtio-comment] [PATCH v5 1/5] virtio-net: Add theory of operation for flow filter Parav Pandit
2023-11-02 13:28 ` [virtio-comment] [PATCH v5 2/5] virtio-net: Add flow filter capabilities read commands Parav Pandit
2023-11-02 13:28 ` [virtio-comment] [PATCH v5 3/5] virtio-net: Add flow filter group life cycle commands Parav Pandit
2023-11-02 13:28 ` [virtio-comment] [PATCH v5 4/5] virtio-net: Add flow filter match entry, action and requests Parav Pandit
2023-11-02 13:28 ` [virtio-comment] [PATCH v5 5/5] virtio-net: Add flow filter device and driver requirements Parav Pandit
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=20231102132825.1865068-1-parav@nvidia.com \
--to=parav@nvidia.com \
--cc=cohuck@redhat.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).