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

[Jerin Jacob <jerinjacobk@gmail.com>]

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


>
> 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/
>