From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>,
"Jerin Jacob" <jerinjacobk@gmail.com>
Cc: "Zhang, Qi Z" <qi.z.zhang@intel.com>, <thomas@monjalon.net>,
<orika@nvidia.com>, <david.marchand@redhat.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
<jerinj@marvell.com>, <ferruh.yigit@amd.com>,
<techboard@dpdk.org>, "Mcnamara, John" <john.mcnamara@intel.com>,
"Zhang, Helin" <helin.zhang@intel.com>, <dev@dpdk.org>
Subject: RE: [PATCH] ethdev: introduce generic flow item and action
Date: Wed, 2 Aug 2023 17:24:40 +0200 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87ABF@smartserver.smartshare.dk> (raw)
In-Reply-To: <DS0PR11MB7442A5C3D7949AD1D9EE7008EB0BA@DS0PR11MB7442.namprd11.prod.outlook.com>
> From: Dumitrescu, Cristian [mailto:cristian.dumitrescu@intel.com]
> Sent: Wednesday, 2 August 2023 16.06
>
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, August 2, 2023 12:22 PM
> >
> > On Wed, Aug 2, 2023 at 4:31 PM Morten Brørup
> > <mb@smartsharesystems.com> wrote:
> > >
> > > > 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.
> >
> > +1
> >
>
> Morten, Jerin,
>
> I think there is a fundamental misunderstanding here: we are not trying to
> provide support for some non-standard vendor-specific features here. What
> we are trying to do is add generic multi-vendor support in RTE_FLOW for
> P4 programmable network devices, which requires supporting flow items
> and actions that are defined directly by the user through their P4 programs
> as opposed to being selected from a pre-defined list.
>
> There are an infinity of flow items and actions that the users can define
> through
> their P4 programs, and they cannot be supported with a finite list of RTE_FLOW
> items and actions:
>
> 1/ Some flow items map directly to the IETF defined protocols, while some
> others do not, and only the user writing the program knows the exact answer;
>
> 2/ Some flow items are simply application-specific (not vendor specific)
> meta-data that (I hope we all accept) is outside of the standardization
> process.
Such items can use a special "reserved" vendor-id.
>
> 3/ Some flow actions map directly to the existing RTE_FLOW actions (especially
> the more straightforward actions such as: packet drop, packet redirection to
> an
> output queue, some specific packet modifications, etc), while the vast
> majority
> of possible actions do not.
>
> Are you saying that the P4 programmable network devices should NOT be
> supported by DPDK and RTE_FLOW?
No, I get the need for this. And I understand that since P4 is compiled to hardware-specific binary blobs, there is a need to put such blobs into DPDK as flow items and actions, instead of the "uncompiled" P4 program.
I am suggesting that instead of adding a completely opaque data type:
Struct item {
Int len; // Length of value in bytes.
Char value[]; // Application specific meaning.
};
...add a semi-opaque data type:
Struct tlv {
Int type; // Vendor specific type.
Int len; // Length of value in bytes.
Char value[]; // (Vendor, Type) specific meaning.
};
Struct item {
Int vendor; // Vendor ID.
Int len; // Length of values in bytes.
Struct tlv values[]; // Array of TLVs.
};
Like RADIUS Vendor-Specific attributes:
https://datatracker.ietf.org/doc/html/rfc2138#section-5.26
Then some (Vendor, Type) fields can be documented (and thus generally understood by DPDK), and some undocumented.
E.g. like Microsoft documented some of theirs in RFC 2548:
https://datatracker.ietf.org/doc/html/rfc2548
Another benefit is that these new "VENDOR-SPECIFIC" flow types can be reused for other purposes than compiled P4 programs.
>
> >
> > >
> > > 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/
> > >
>
> Regards,
> Cristian
next prev parent reply other threads:[~2023-08-02 15:24 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
2023-08-02 11:21 ` Jerin Jacob
2023-08-02 14:06 ` Dumitrescu, Cristian
2023-08-02 15:24 ` Morten Brørup [this message]
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=98CBD80474FA8B44BF855DF32C47DC35D87ABF@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=jerinjacobk@gmail.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).