RE: [PATCH] ethdev: introduce generic flow item and action

["Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>]

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

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