RE: [RFC] lib/ethdev: introduce table driven APIs

["Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>]

> -----Original Message-----
> From: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Sent: Wednesday, July 19, 2023 2:39 PM
> To: Ori Kam <orika@nvidia.com>; Jerin Jacob <jerinjacobk@gmail.com>;
> Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> david.marchand@redhat.com; Richardson, Bruce
> <bruce.richardson@intel.com>; jerinj@marvell.com; ferruh.yigit@amd.com;
> Mcnamara, John <john.mcnamara@intel.com>; Zhang, Helin
> <helin.zhang@intel.com>; techboard@dpdk.org; dev@dpdk.org; Ivan Malov
> <ivan.malov@arknetworks.am>
> Subject: RE: [RFC] lib/ethdev: introduce table driven APIs
> 
> Hi folks,
> 
> > -----Original Message-----
> > From: Ori Kam <orika@nvidia.com>
> > Sent: Tuesday, June 20, 2023 12:11 PM
> > To: Jerin Jacob <jerinjacobk@gmail.com>; Zhang, Qi Z
> > <qi.z.zhang@intel.com>
> > Cc: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; NBU-Contact-
> > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > david.marchand@redhat.com; Richardson, Bruce
> > <bruce.richardson@intel.com>; jerinj@marvell.com;
> ferruh.yigit@amd.com;
> > Mcnamara, John <john.mcnamara@intel.com>; Zhang, Helin
> > <helin.zhang@intel.com>; techboard@dpdk.org; dev@dpdk.org; Ivan
> Malov
> > <ivan.malov@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