> -----Original Message----- > From: Morten Brørup <m...@smartsharesystems.com> > Sent: Thursday, August 3, 2023 1:56 AM > To: Dumitrescu, Cristian <cristian.dumitre...@intel.com>; Ori Kam > <or...@nvidia.com>; Jerin Jacob <jerinjac...@gmail.com> > Cc: Zhang, Qi Z <qi.z.zh...@intel.com>; NBU-Contact-Thomas Monjalon > (EXTERNAL) <tho...@monjalon.net>; david.march...@redhat.com; > Richardson, Bruce <bruce.richard...@intel.com>; jer...@marvell.com; > ferruh.yi...@amd.com; techbo...@dpdk.org; Mcnamara, John > <john.mcnam...@intel.com>; Zhang, Helin <helin.zh...@intel.com>; > dev@dpdk.org > Subject: RE: [PATCH] ethdev: introduce generic flow item and action > > > From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com] > > Sent: Wednesday, 2 August 2023 19.23 > > > > > From: Ori Kam <or...@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 <or...@nvidia.com> > > > > Sent: Wednesday, August 2, 2023 6:47 PM > > > > > > > > Hi Qi > > > > > > > > > -----Original Message----- > > > > > From: Morten Brørup <m...@smartsharesystems.com> > > > > > Sent: Wednesday, August 2, 2023 6:25 PM > > > > > > > > > > > From: Dumitrescu, Cristian > > [mailto:cristian.dumitre...@intel.com] > > > > > > Sent: Wednesday, 2 August 2023 16.06 > > > > > > > > > > > > > From: Jerin Jacob <jerinjac...@gmail.com> > > > > > > > Sent: Wednesday, August 2, 2023 12:22 PM > > > > > > > > > > > > > > On Wed, Aug 2, 2023 at 4:31 PM Morten Brørup > > > > > > > <m...@smartsharesystems.com> wrote: > > > > > > > > > > > > > > > > > From: Morten Brørup [mailto:m...@smartsharesystems.com] > > > > > > > > > Sent: Wednesday, 2 August 2023 12.25 > > > > > > > > > > > > > > > > > > > From: Qi Zhang [mailto:qi.z.zh...@intel.com] > > > > > > > > > > Sent: Wednesday, 2 August 2023 19.35 > > > > > > > > > > > > > > > > > > > > From: Cristian Dumitrescu > > <cristian.dumitre...@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
