> -----Original Message----- > From: Dumitrescu, Cristian <cristian.dumitre...@intel.com> > Sent: Wednesday, July 19, 2023 2:39 PM > To: Ori Kam <or...@nvidia.com>; Jerin Jacob <jerinjac...@gmail.com>; > Zhang, Qi Z <qi.z.zh...@intel.com> > Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) <tho...@monjalon.net>; > david.march...@redhat.com; Richardson, Bruce > <bruce.richard...@intel.com>; jer...@marvell.com; ferruh.yi...@amd.com; > Mcnamara, John <john.mcnam...@intel.com>; Zhang, Helin > <helin.zh...@intel.com>; techbo...@dpdk.org; dev@dpdk.org; Ivan Malov > <ivan.ma...@arknetworks.am> > Subject: RE: [RFC] lib/ethdev: introduce table driven APIs > > Hi folks, > > > -----Original Message----- > > From: Ori Kam <or...@nvidia.com> > > Sent: Tuesday, June 20, 2023 12:11 PM > > To: Jerin Jacob <jerinjac...@gmail.com>; Zhang, Qi Z > > <qi.z.zh...@intel.com> > > Cc: Dumitrescu, Cristian <cristian.dumitre...@intel.com>; NBU-Contact- > > Thomas Monjalon (EXTERNAL) <tho...@monjalon.net>; > > david.march...@redhat.com; Richardson, Bruce > > <bruce.richard...@intel.com>; jer...@marvell.com; > ferruh.yi...@amd.com; > > Mcnamara, John <john.mcnam...@intel.com>; Zhang, Helin > > <helin.zh...@intel.com>; techbo...@dpdk.org; dev@dpdk.org; Ivan > Malov > > <ivan.ma...@arknetworks.am> > > 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
