> -----Original Message----- > From: Dumitrescu, Cristian <[email protected]> > Sent: Wednesday, July 19, 2023 2:39 PM > To: Ori Kam <[email protected]>; Jerin Jacob <[email protected]>; > Zhang, Qi Z <[email protected]> > Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) <[email protected]>; > [email protected]; Richardson, Bruce > <[email protected]>; [email protected]; [email protected]; > Mcnamara, John <[email protected]>; Zhang, Helin > <[email protected]>; [email protected]; [email protected]; Ivan Malov > <[email protected]> > Subject: RE: [RFC] lib/ethdev: introduce table driven APIs > > Hi folks, > > > -----Original Message----- > > From: Ori Kam <[email protected]> > > Sent: Tuesday, June 20, 2023 12:11 PM > > To: Jerin Jacob <[email protected]>; Zhang, Qi Z > > <[email protected]> > > Cc: Dumitrescu, Cristian <[email protected]>; NBU-Contact- > > Thomas Monjalon (EXTERNAL) <[email protected]>; > > [email protected]; Richardson, Bruce > > <[email protected]>; [email protected]; > [email protected]; > > Mcnamara, John <[email protected]>; Zhang, Helin > > <[email protected]>; [email protected]; [email protected]; Ivan > Malov > > <[email protected]> > > Subject: RE: [RFC] lib/ethdev: introduce table driven APIs > > > <snip> > > > > > > > Yes. We need to change the backend compiler to understand the rte_flow > > > mapping to p4 to avoid any translation cost. > > +1 > > I think the idea is that the complier will convert to rte_flow and supply > some > > mapping file so when application uses some name it will be translated to > the > > correct > > preconfigured rte_flow action > > Sorry to join late to this thread. > > Let me try to clarify the role of the P4 compiler: > > 1. P4 compiler is for the data path only, while this proposal is for a control > path API. > > 2. The P4 program simply defines the data path pipeline, i.e. the table > topology that > Ivan was mentioning. The P4 compiler takes this P4 program as input and > translates > it to a sort of firmware that the HW understands and loads to create that data > path. > > 3. The P4 program defines the key and action formats for each table, but it > does NOT > contain the set of entries (key/action pairs) for each table; the actual table > entries are > populated post-init by the user using a control path API such as RTE_FLOW or > other. > > So what Qi's proposal is about is a control path API to populate the tables, > an > API that > is similar to the RTE_FLOW API, and not about a data path API to define a > topology of > tables (the table topology is either hardcoded at HW design time or > configured in HW at > init time by "firmware" produced by the P4 compiler out of a P4 program). > > Makes sense? > > Regards, > Cristian
Hi folks, Based on community feedback, we realized that introducing a new and significant API that overlaps in scope with the existing RTE_FLOW API might not be the best path forward. Therefore, we are now looking for ways to support our hardware capabilities with minimal extensions to the RTE_FLOW API, hence Qi and myself just send this new proposal: https://mails.dpdk.org/archives/dev/2023-August/273703.html Please review this new RFC and provide your input. Thanks for the feedback! Regards, Qi and Cristian
