> -----Original Message----- > From: Jerin Jacob <jerinjac...@gmail.com> > Sent: Thursday, June 15, 2023 2:21 PM > To: Zhang, Qi Z <qi.z.zh...@intel.com> > Cc: Ori Kam <or...@nvidia.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 > > On Thu, Jun 15, 2023 at 11:33 AM Zhang, Qi Z <qi.z.zh...@intel.com> wrote: > > > > Hi Jerin: > > Hi Qi > > > > > > -----Original Message----- > > > From: Jerin Jacob <jerinjac...@gmail.com> > > > Sent: Thursday, June 15, 2023 12:58 PM > > > To: Zhang, Qi Z <qi.z.zh...@intel.com> > > > Cc: Ori Kam <or...@nvidia.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 > > > > > > On Thu, Jun 15, 2023 at 7:55 AM Zhang, Qi Z <qi.z.zh...@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 <or...@nvidia.com> > > > > > Sent: Thursday, June 15, 2023 2:31 AM > > > > > To: Zhang, Qi Z <qi.z.zh...@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 > > > > > Cc: Mcnamara, John <john.mcnam...@intel.com>; Zhang, Helin > > > > > <helin.zh...@intel.com>; techbo...@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? > > > > 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. > > I meant vdev + rawdev combo can be used to talk to FW.
OK, I will comment this together when vdev + rawdev be mentioned again at below. > > > > 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. > > See above. > > There is a lot of overlap between rte_flow and table driven API is the issue. > To make things worst, there is also lib/table/ API. I assume this is just the concern about naming? At least, they are target to different usage. > > > > > > > > > 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. > > Isn't same? If not, Please elaborate on "P4 to rte_flow mapping" vs > "offloading rte_flow into a P4-based pipeline" OK I guess the gap here is I may not fully understand is how we defined the case of item(2) Existing HW and SW drivers implements rte-flow driver. If we assume that the application is not P4-aware, it will consume existing rte_flow API for flow offloading. In this case, all we need to do is implement it in the PMD, which will be a highly hardware-specific task. Do you propose generalizing this common part? On the other hand, if the application is P4-aware, we can assume that there won't be a need for translation between P4 tokens and rte_flow protocols in the PMD. > > > > > > 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. > > Counter argument for that is, If the P4 is API contract then why bother with > DPDK abstraction use vdev + rawdev talk to FW as PMD is just passing > message to FW. FW is doing the heavy lifting anyway. We are attempting to generalize the common aspects, considering that P4 Runtime is a standard API. It appears worthwhile to expose certain APIs that can assist its backend implementation. I may need some time to understand the concept of vdev +rawdev combo solution, currently one question in my mind is: in this solution, is above consideration covered? Thanks Qi > > > > > > 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.
