Hi > -----Original Message----- > From: Ferruh Yigit <ferruh.yi...@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.dumitre...@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 ......
