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

[Jerin Jacob <jerinjacobk@gmail.com>]

On Thu, Jun 15, 2023 at 7:55 AM Zhang, Qi Z <qi.z.zhang@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@nvidia.com>
> > Sent: Thursday, June 15, 2023 2:31 AM
> > To: Zhang, Qi Z <qi.z.zhang@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
> > Cc: Mcnamara, John <john.mcnamara@intel.com>; Zhang, Helin
> > <helin.zhang@intel.com>; techboard@dpdk.org; dev@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? If driver writer care about using
DPDK for driver framework for EAL services, simply using vdev etc
would be enough. Right?

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.

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.