From: Ori Kam <orika@nvidia.com>
To: "Morten Brørup" <mb@smartsharesystems.com>,
"Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>,
"Jerin Jacob" <jerinjacobk@gmail.com>
Cc: "Zhang, Qi Z" <qi.z.zhang@intel.com>,
"NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>,
"david.marchand@redhat.com" <david.marchand@redhat.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"jerinj@marvell.com" <jerinj@marvell.com>,
"ferruh.yigit@amd.com" <ferruh.yigit@amd.com>,
"techboard@dpdk.org" <techboard@dpdk.org>,
"Mcnamara, John" <john.mcnamara@intel.com>,
"Zhang, Helin" <helin.zhang@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: RE: [PATCH] ethdev: introduce generic flow item and action
Date: Wed, 2 Aug 2023 15:47:28 +0000 [thread overview]
Message-ID: <MW2PR12MB4666530D9A316362DF8BD3F8D60BA@MW2PR12MB4666.namprd12.prod.outlook.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87ABF@smartserver.smartshare.dk>
Hi Qi
> -----Original Message-----
> From: Morten Brørup <mb@smartsharesystems.com>
> Sent: Wednesday, August 2, 2023 6:25 PM
>
> > 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
> > >
+1 I understand that this is supposed to be generic, but how can it?
how do you know if PMD supports this?
what if each PMD needs different configurations?
In addition how can you handle number of those action and items?
For example if I have match on protocol X and Y and do actions Z and W
each one of those can be generic item.
if you have a way to define a standard why to read such actions then we have something to talk about.
> >
> > 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.
>
Can you show me what items/actions are missing in rte_flow?
> >
> > 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.
> };
>
But since you didn't define a known protocol for PMD to read the data how
2 pmds can use the same action?
> ...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:47 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
2023-08-02 15:47 ` Ori Kam [this message]
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=MW2PR12MB4666530D9A316362DF8BD3F8D60BA@MW2PR12MB4666.namprd12.prod.outlook.com \
--to=orika@nvidia.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=mb@smartsharesystems.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).