From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Qi Zhang" <qi.z.zhang@intel.com>, <thomas@monjalon.net>,
<orika@nvidia.com>, <david.marchand@redhat.com>,
<bruce.richardson@intel.com>, <jerinj@marvell.com>,
<ferruh.yigit@amd.com>
Cc: <techboard@dpdk.org>, <john.mcnamara@intel.com>,
<helin.zhang@intel.com>, <dev@dpdk.org>,
"Cristian Dumitrescu" <cristian.dumitrescu@intel.com>
Subject: RE: [PATCH] ethdev: introduce generic flow item and action
Date: Wed, 2 Aug 2023 13:01:05 +0200 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87AB9@smartserver.smartshare.dk> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87AB8@smartserver.smartshare.dk>
> From: Morten Brørup [mailto:mb@smartsharesystems.com]
> Sent: Wednesday, 2 August 2023 12.25
>
> > From: Qi Zhang [mailto:qi.z.zhang@intel.com]
> > Sent: Wednesday, 2 August 2023 19.35
> >
> > From: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> >
> > For network devices that are programmable through languages such as
> > the P4 language, there are no pre-defined flow items and actions.
> >
> > The format of the protocol header and metadata fields that are used to
> > specify the flow items that make up the flow pattern, as well as the
> > flow actions, are all defined by the program, with an infinity of
> > possible combinations, as opposed to being selected from a finite
> > pre-defined list.
> >
> > It is virtually impossible to pre-define all the flow items and the
> > flow actions that programs might ever use, as these are only limited
> > by the set of HW resources and the program developer's imagination.
> >
> > To support the programmable network devices, we are introducing:
> >
> > * A generic flow item: The flow item is expressed as an array of bytes
> > of a given length, whose meaning is defined by the program loaded by
> > the network device.
>
> The flow item is not "generic", it is "opaque": Only the application knows
> what this flow item does.
>
> I hate the concept for two reasons:
> 1. The inability for applications to detect which flow items the underlying
> hardware supports.
> 2. The risk that vendors will use this instead of introducing new flow item
> types, available for anyone to implement.
After further consideration, there might be a middle ground.
Consider Vendor-Specific attributes for DHCP and RADIUS, or SNMP MIBs...
Any vendor is free to add his own, proprietary special-purpose attributes, without going through the standardization process. (This is the key challenge this patch seems to be aiming at.)
The vendor might publish these attributes, and other vendors may implement them too.
And in order to prevent collisions, the Vendor-Specific attributes contain a globally unique vendor ID, such as the Private Enterprise Number [1] managed by IANA.
If similar principles can be worked into the patch, I can support it.
Preferably, there should also be a means for applications to query if specific Vendor-Specific flow items and actions are supported or not.
[1]: https://www.iana.org/assignments/enterprise-numbers/
next prev parent reply other threads:[~2023-08-02 11:01 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-02 17:34 Qi Zhang
2023-08-02 9:37 ` Zhang, Qi Z
2023-08-02 10:25 ` Morten Brørup
2023-08-02 11:01 ` Morten Brørup [this message]
2023-08-02 11:21 ` Jerin Jacob
2023-08-02 14:06 ` Dumitrescu, Cristian
2023-08-02 15:24 ` Morten Brørup
2023-08-02 15:47 ` Ori Kam
2023-08-02 16:06 ` Ori Kam
2023-08-02 17:22 ` Dumitrescu, Cristian
2023-08-02 17:56 ` Morten Brørup
2023-08-03 1:05 ` Zhang, Qi Z
2023-08-03 13:57 ` Morten Brørup
2023-08-16 13:23 ` Dumitrescu, Cristian
2023-08-16 14:20 ` Morten Brørup
2023-08-16 17:08 ` Ferruh Yigit
2023-08-16 17:18 ` Dumitrescu, Cristian
2023-08-16 16:19 ` DPDK community: RTE_FLOW support for P4-programmable devices Dumitrescu, Cristian
2023-08-27 7:48 ` Ori Kam
2023-08-28 16:12 ` Dumitrescu, Cristian
2023-08-29 7:38 ` Jerin Jacob
2023-08-29 10:18 ` Ferruh Yigit
2023-08-31 10:32 ` Ori Kam
2023-08-31 13:42 ` Stephen Hemminger
2023-09-01 2:07 ` Jerin Jacob
2023-09-01 6:57 ` Ori Kam
2023-09-01 9:52 ` Jerin Jacob
2023-09-04 7:45 ` Ferruh Yigit
2023-09-06 8:30 ` Ori Kam
2023-09-11 20:20 ` Dumitrescu, Cristian
2023-08-02 16:56 ` [PATCH] ethdev: introduce generic flow item and action Dumitrescu, Cristian
2023-08-03 8:39 ` Ori Kam
2023-08-16 13:12 ` Dumitrescu, Cristian
2023-08-02 16:14 ` Dumitrescu, Cristian
2023-08-02 14:06 ` Dumitrescu, Cristian
2023-08-02 14:54 ` Morten Brørup
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=98CBD80474FA8B44BF855DF32C47DC35D87AB9@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=bruce.richardson@intel.com \
--cc=cristian.dumitrescu@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=helin.zhang@intel.com \
--cc=jerinj@marvell.com \
--cc=john.mcnamara@intel.com \
--cc=orika@nvidia.com \
--cc=qi.z.zhang@intel.com \
--cc=techboard@dpdk.org \
--cc=thomas@monjalon.net \
/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 NNTP newsgroup(s).