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 <or...@nvidia.com> wrote: > 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 ...... > >
