RE: DPDK community: RTE_FLOW support for P4-programmable devices

[Ori Kam <orika@nvidia.com>]

Hi

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@amd.com>
> Sent: Tuesday, August 29, 2023 1:18 PM
> devices
> 
> On 8/29/2023 8:38 AM, Jerin Jacob wrote:
> > On Mon, Aug 28, 2023 at 9:43 PM Dumitrescu, Cristian
> > <cristian.dumitrescu@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@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.
> >
> 
> 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?
> 
> > # 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 ......