> -----Original Message----- > From: Jerin Jacob <jerinjac...@gmail.com> > Sent: Wednesday, August 2, 2023 12:22 PM > To: Morten Brørup <m...@smartsharesystems.com> > Cc: Zhang, Qi Z <qi.z.zh...@intel.com>; tho...@monjalon.net; > or...@nvidia.com; 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; Dumitrescu, Cristian > <cristian.dumitre...@intel.com> > Subject: Re: [PATCH] ethdev: introduce generic flow item and action > > 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 >
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. 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? > > > > > 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
