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
