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

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

Hi Morten,

<snip>

> > >
> > > 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.
> 
> If the flow item itself doesn't have a "type" field (identifying how to interpret
> the blob), you might have two different NICs using each their own blob
> format. The NIC must be able to determine if a given flow item is of a type it
> can understand, before it tries to parse the blob in it.
> 
> This is why the "struct rte_flow_item" has a "type" field. It tells the HW how
> to interpret the values in a flow item.
> 
> If we introduce a "generic" flow item type, it can only be used for multiple
> purposes (i.e. both P4, but also other purposes than P4) if it has a "sub-type"
> field. Otherwise, someone will create a "generic" flow item containing a P4
> program and send it to a NIC, which uses the "generic" flow item type for
> other program types, e.g. a cBPF program. And this cBPF capable NIC has no
> way to detect that the blob in the flow item is not a cBPF program, but a P4
> program. The P4 capable NIC will accept the P4 program, but will be confused
> when sent the cBPF program understood by the first NIC.
> 
> So I am suggesting that the "generic" flow items and actions follow an existing
> and well known design patterns for how to identify the meaning of blobs:
> Include a Vendor-ID followed by vendor-specific TLV formatted data.
> 
> As I wrote initially, I am opposed to introducing uninterpretable blobs into
> DPDK. Flow items/actions need to be well defined. Allowing "Vendor-Specific"
> flow items/actions is a workaround that allows you to bypass the normal
> standardization process.
> 

I would be happy to add mechanisms to describe the user-defined flow items
and actions in greater detail. Would you be able to provide some examples for
your proposal for a flow item and a flow action of your choice, please? Thanks!

One thing I would want to stress here: the flow items and flow actions are
defined exclusively by the user (through their P4 program) without any
knowledge or intervention from the HW vendor, so any TLVs / helper fields
must be populated by the user as opposed to the HW vendor.

<snip>

Regards,
Cristian