<div dir="auto">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.</div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 31, 2023, 12:32 PM Ori Kam <<a href="mailto:orika@nvidia.com">orika@nvidia.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi > -----Original Message----- > From: Ferruh Yigit <<a href="mailto:ferruh.yigit@amd.com" target="_blank" rel="noreferrer">ferruh.yigit@amd.com</a>> > 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 > > <<a href="mailto:cristian.dumitrescu@intel.com" target="_blank" rel="noreferrer">cristian.dumitrescu@intel.com</a>> 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 > >>>> <a href="https://mails.dpdk.org/archives/dev/2023-August/273703.html" rel="noreferrer noreferrer" target="_blank">https://mails.dpdk.org/archives/dev/2023-August/273703.html</a> 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 <a href="mailto:dev@dpdk.org" target="_blank" rel="noreferrer">dev@dpdk.org</a>, 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 ...... </blockquote></div>