It also introduces lots of new test conditions. For example, can a P4 flow
be deleted, supersed, or read by a flow created by rte_flow.

On Thu, Aug 31, 2023, 12:32 PM Ori Kam <orika@nvidia.com> wrote:

> 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 ......
>
>