DPDK community: RTE_FLOW support for P4-programmable devices

[Jerin Jacob]

On Mon, Aug 28, 2023 at 9:43 PM Dumitrescu, Cristian
<cristian.dumitrescu at intel.com> wrote:
>
> > > We just set up a community call for next week to discuss in more details the
> > > proposal for RTE_FLOW extensions to support P4-programmable devices
> > > https://mails.dpdk.org/archives/dev/2023-August/273703.html and look for
> > > ways to converge and make progress.
> > >
> > > All the people from To: and CC: are already invited. To avoid cluttering
> > people's
> > > calendars, I did not add dev at dpdk.org, so if anybody else wants to attend,
> > > please send me a private email and I will be happy to forward the invite.
> > >
> > > Thanks,
> > > Cristian
>
> Attendees: Morten Brorup, Jerin Jacob, Anoob Joseph, Vipin Varghese, Qi Zhang,
> Cristian Dumitrescu
>
> 1. Ori (RTE_FLOW maintainer) and others were not present, probably on vacation,
> hopefully they will be able to attend the next call on this topic. Ferruh had a last
> minute conflict that he could not avoid.
>
> 2. Cristian presented a few slides (attached) with the problem statement, current
> RTE_FLOW gaps for P4-programmable devices and the list of current solution
> proposals.
>
> 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.

# All we need "char buffer//string" based communication ethdev <-> app.