From: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
To: "Ori Kam" <orika@nvidia.com>,
"Morten Brørup" <mb@smartsharesystems.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 17:22:40 +0000 [thread overview]
Message-ID: <PH7PR11MB7450AA53C689604CCA00E4BEEB0BA@PH7PR11MB7450.namprd11.prod.outlook.com> (raw)
In-Reply-To: <MW2PR12MB4666530C86BE0EEFD2166C39D60BA@MW2PR12MB4666.namprd12.prod.outlook.com>
> -----Original Message-----
> From: Ori Kam <orika@nvidia.com>
> Sent: Wednesday, August 2, 2023 5:06 PM
> To: Ori Kam <orika@nvidia.com>; 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;
> 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
>
> Hi Qi,
>
> In addition to my previous email,
> I fully support you’re your idea to update the rte_flow API
> so it will be easier for P4 integration, I just think the suggested approach is not
> the correct one at least not as appears in the RFC.
>
> I think it will be good if we can discuss some uses cases you are having
> with the API/implementation and see what is the best way to solve them.
> The main idea is not to re-invent the wheel, but to solve issues.
Yes, fully agree, it would be great meet and talk through this, as we did it in the
past for other issues. What days & time next week would be good for people?
Meanwhile, some answers below.
>
> To summarize, as I see it there are several issues:
> 1. no protocol is defined so different PMD can't translate it.
The format of the flow items is defined by the P4 program, so all the HW devices
(from the same or from different vendors) that are able to successfully load the
given P4 program will have the same understanding of the flow items.
> 2. even the same PMD doesn't know what is the action, unless you plan that
> this will move
> directly to the HW, in this case, the action will be HW dependent.
The processing of each flow action, as well as the number of arguments and the
format of each action argument, is defined by the P4 program, so all the HW
devices (from the same or from different vendors) that are able to successfully
load the given P4 program will have the same understanding of the flow actions.
> 3. when application should use this new action or the old ones.
I guess it is good to clarify that there are two application: a data path application
(the P4 program) that defines the packet processing pipeline, and a control path
application that invokes RTE_FLOW to add/delete the flows on the device. I guess
we are now referring to the control path app.
Whenever the P4 program (the data path app) that is currently loaded on the
device is defining and using flow actions that perform identical processing to one
of the existing pre-defined RTE_FLOW actions (such as packet drop, packet
redirection to a given output queue, packet modifications, etc), then the app
(the control path app) can accept these actions as well.
But in the (frequent) case that the user's P4 program defines actions that do not
map to an RTE_FLOW action from the pre-defined list, then the app has no other
option but to use the newly proposed generic flow action in order to specify
(through the action_id field) the exact flow action from the P4 program.
Makes sense?
>
>
> Thanks,
> Ori
>
Regards,
Cristian
> > -----Original Message-----
> > From: Ori Kam <orika@nvidia.com>
> > Sent: Wednesday, August 2, 2023 6:47 PM
> >
> > 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 17:22 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
2023-08-02 16:06 ` Ori Kam
2023-08-02 17:22 ` Dumitrescu, Cristian [this message]
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=PH7PR11MB7450AA53C689604CCA00E4BEEB0BA@PH7PR11MB7450.namprd11.prod.outlook.com \
--to=cristian.dumitrescu@intel.com \
--cc=bruce.richardson@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=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).