On Thu, Aug 31, 2023 at 4:02 PM Ori Kam <or...@nvidia.com> wrote: > > Hi
> > >> > > >> 3. Everybody on the call agreed that the P4-programmable devices from > > Intel, > > >> AMD and others need to be fully supported by DPDK and that there are > > some > > >> gaps in RTE_FLOW to be fixed for supporting these devices. > > > > > > Personally, It makes sense to me to have normative DPDK API to send p4 > > > runtime message to the > > > ethdev so that we have "vendor neutral + DPDK based" p4 runtime backend. > > > > > > I prefer to have specialized ethdev ops for this due to the following > > > reasons. > > > > > > # If the ethdev has both real TCAM based HW(for existing rte_flow > > > patterns and actions) and SW agent to receive P4 runtime message etc. > > > Typically, it needs to take a different path in driver to talk. Assume, > > > if you > > > have cascaded patterns/actions, One is targeted for TCAM and other for > > > SW agent for p4, one > > > need to have serious amount checking for dispatching.It complicates > > > the driver and forbid to have > > > driver optimization especially cases for templates etc. if user making > > > rules for both category of HW. > > > > > > > Indeed I am not against dedicated APIs for P4 runtime backend. > > > > But assuming there is a dedicated rte_flow item for P4, how it is > > different than dedicated API in above scenario? > > If driver detects P4 runtime specific rule, it can bail it out to SW agent. > > Can you please elaborate the complexity it introduces? Assume, normal existing rte-flow programming include a bunch of register writes and p4 runtime backend is more of SW ring. If a template has both patterns and actions as cascaded, it will be difficult for driver to optimize the template. > > > > > # All we need "char buffer//string" based communication ethdev <-> app. > > > > > > > Yes, and both a dedicated API or dedicated rte_flow item can provide > > medium for this communication. > > > > rte_flow one has flexibility & extensibility advantages, but maybe not > > as straightforward as an API. > > I think not using the rte_flow will also require duplication of all the rule > handling functions and table creations, for example aync rule create/destroy > query ...... Yes. That is a fair point. I am OK with exposing as rte_flow. As a driver implementation note, to get rid of the above problem, driver can choose to have pseudo ethdev devices for p4 if needed(if driver finds difficult to combine TCAM based on HW rules and p4 runtime rule). >
