From: "Zhang, Qi Z" <qi.z.zhang@intel.com>
To: "Morten Brørup" <mb@smartsharesystems.com>,
"Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>,
"Ori Kam" <orika@nvidia.com>,
"Jerin Jacob" <jerinjacobk@gmail.com>
Cc: "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: Thu, 3 Aug 2023 01:05:13 +0000 [thread overview]
Message-ID: <DM4PR11MB59940F8B256243F99CA55C20D708A@DM4PR11MB5994.namprd11.prod.outlook.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87AC2@smartserver.smartshare.dk>
> -----Original Message-----
> From: Morten Brørup <mb@smartsharesystems.com>
> Sent: Thursday, August 3, 2023 1:56 AM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Ori Kam
> <orika@nvidia.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
>
> > From: Dumitrescu, Cristian [mailto:cristian.dumitrescu@intel.com]
> > Sent: Wednesday, 2 August 2023 19.23
> >
> > > From: Ori Kam <orika@nvidia.com>
> > > Sent: Wednesday, August 2, 2023 5:06 PM
> > >
> > > 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?
>
> My calendar is pretty much all open these days, so anytime work hours in the
> Central European time zone works for me.
>
> >
> > 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.
>
> If the P4 flow items/actions are standardized by some P4 organization or
> similar, they can be enumerated and defined as DPDK flow items/actions. At
> least the ones that are standardized.
>
> And if you (for flexibility or other reasons) need to bypass the RTE_FLOW
> standardization process (getting ACKs etc. on the DPDK mailing list) for faster
> integration of new DPDK flow items/actions, it does make sense to define a
> generic flow item (and action) for this purpose (and not just for P4).
>
> In order to avoid conflicts between P4 and non-P4 generic flow items/actions,
> the generic type should include information about how to interpret the
> information, which is why I suggest making it a Vendor-Specific type, with
> vendor-specific TLV's (managed by the vendor), like the RADIUS Vendor-
> Specific attributes I compared to, instead of just an opaque blob.
I like this idea, but it is not necessary to introduce a vendor-specific type, it could be considered a device-specific type (or port-specific in the context of DPDK).
However, the PMD can manage a dictionary, enabling users to query about the format of each generic item or action if we can expose a set of query APIs.
But I guess we don't need vendor-id / vendor-type as RADIUS does, as we have port_id here.
>
> The P4 standardized items/actions can use the Vendor ID of the P4 standards
> organization.
>
> The non-standardized items/actions can use the Vendor ID of the hardware
> vendor or the application developer.
>
> >
> > > 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-03 1:05 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
2023-08-02 17:56 ` Morten Brørup
2023-08-03 1:05 ` Zhang, Qi Z [this message]
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=DM4PR11MB59940F8B256243F99CA55C20D708A@DM4PR11MB5994.namprd11.prod.outlook.com \
--to=qi.z.zhang@intel.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=orika@nvidia.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).