[RFC] lib/ethdev: introduce table driven APIs

[Zhang, Qi Z]

Hi Jerin:

> -----Original Message-----
> From: Jerin Jacob <jerinjacobk at gmail.com>
> Sent: Thursday, June 15, 2023 12:58 PM
> To: Zhang, Qi Z <qi.z.zhang at intel.com>
> Cc: Ori Kam <orika at nvidia.com>; NBU-Contact-Thomas Monjalon (EXTERNAL)
> <thomas at monjalon.net>; david.marchand at redhat.com; Richardson, Bruce
> <bruce.richardson at intel.com>; jerinj at marvell.com; ferruh.yigit at amd.com;
> Mcnamara, John <john.mcnamara at intel.com>; Zhang, Helin
> <helin.zhang at intel.com>; techboard at dpdk.org; dev at dpdk.org; Ivan Malov
> <ivan.malov at arknetworks.am>
> Subject: Re: [RFC] lib/ethdev: introduce table driven APIs
> 
> On Thu, Jun 15, 2023 at 7:55 AM Zhang, Qi Z <qi.z.zhang at intel.com> wrote:
> >
> > Hi Ori:
> >
> >         Thank you for your review!
> >         Comment inline.
> >         Please let me know if anything I missed.
> >
> > Thanks
> > Qi
> >
> > > -----Original Message-----
> > > From: Ori Kam <orika at nvidia.com>
> > > Sent: Thursday, June 15, 2023 2:31 AM
> > > To: Zhang, Qi Z <qi.z.zhang at intel.com>; NBU-Contact-Thomas Monjalon
> > > (EXTERNAL) <thomas at monjalon.net>; david.marchand at redhat.com;
> > > Richardson, Bruce <bruce.richardson at intel.com>; jerinj at marvell.com;
> > > ferruh.yigit at amd.com
> > > Cc: Mcnamara, John <john.mcnamara at intel.com>; Zhang, Helin
> > > <helin.zhang at intel.com>; techboard at dpdk.org; dev at dpdk.org
> > > Subject: RE: [RFC] lib/ethdev:
> > >
> > > Hi Qi,
> > >
> > >
> > > 1. it may be useful to get some general calling flow what comes from
> > > the application, what comes from the compiler.
> > > Simple example will be good.
> >
> > An example of decap VXLAN TCP flow is explained in problem statement
> > (http://mails.dpdk.org/archives/dev/2023-May/267719.html)
> > covering the following information.
> >
> > 1. the p4 source code, the definition of the table and actions 2. the
> > table / action hints generated by the compiler, details to each fields.
> > 3. How the Control Plane Application utilizes the P4 Runtime API to
> > program the rule with the respective table and action IDs
> >
> > The DPDK PMD is responsible for loading the hints generated by the
> compiler.
> > This enables the PMD to accept requests from the P4 Runtime and reject
> any incompatible request.
> 
> I see two different types of device/system category
> 
> 1) HW + SW/FW combination that really understands p4 structures and job
> of the driver to is to give work to HW/SW as p4 structure generated from
> vendor specific compiler and runtime gRPC message
> 2) Existing HW and SW drivers implements rte-flow driver.
> 
> For item (1), if end user application is using P4 program and P4 runtime and
> this is _API contract_ to application, Not sure why end user care it is DPDK
> PMD or not? 

That's true. DPDK as a platform that manage the hardware, it is required to provide a channel that connects applications with the hardware responsible for implementing the contract.
In this context, the PMD (ethdev) serves as the conduit that can fulfill this requirement.

> If driver writer care about using DPDK for driver framework for
> EAL services, simply using vdev etc would be enough. Right?

I may not fully understand this, a vdev should have a device type, I didn't see any issue for a ethdev vdev to implement the table-driven APIs.

> 
> For item (2), I think, interest is how to offload p4 workload to rte_flow. So
> that _existing_ drivers implements rte_flow can support
> p4 naturally in addition to existing rte_flow API. If that is direction, then we
> need to the following.

While the idea of offloading P4 to rte_flow is certainly interesting, it doesn't seem to directly address our initial problem statement.
The primary objective is to find a solution for offloading rte_flow into a P4-based pipeline.

We have identified two distinct use cases:

P4-Aware Applications:

For applications that are already P4 aware, the proposal suggests the introduction of a new set of APIs to rte_flow. 
These APIs aim to facilitate seamless integration between DPDK and P4 aware applications.

Non-P4 Aware Applications:

In the case, our focus is on bridging the existing rte_flow API to the underlying P4 pipeline. 
Currently, we haven't identified any significant gaps in the DPDK APIs.
The key challenge lies in handling the translation process within the PMD

Thanks 
Qi

> 
> a)Improve p4-dpdk compiler backend or add new compiler DPDK  backend to
> understand the rte_flow and have helper library in DPDK to understand the
> compiler spec file to translate to rte_flow objects b)Similar case for runtime
> API. i.e Have helper functions to translate
> p4 MatchField name etc to appropriate rte_flow objects.
> c)Enhance base rte_flow specification if there are any fundamental gaps to
> express the new pattern or actions (which is not specific to
> p4 and applicable for any flow matching use case)
> 
> If we introduce compiler in the pipeline, a lot of translation will get in the
> slowpath. And for runtime API, the translation primarily will be name to
> rte_flow object lookup (which is not that costly) and using
> rte_flow_template etc. to amortize the cost by making it burst.
> 
>  Just my 2c.