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