From: "Zhang, Qi Z" <qi.z.zhang@intel.com>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: Ori Kam <orika@nvidia.com>,
"NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>,
"david.marchand@redhat.com" <david.marchand@redhat.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"jerinj@marvell.com" <jerinj@marvell.com>,
"ferruh.yigit@amd.com" <ferruh.yigit@amd.com>,
"Mcnamara, John" <john.mcnamara@intel.com>,
"Zhang, Helin" <helin.zhang@intel.com>,
"techboard@dpdk.org" <techboard@dpdk.org>,
"dev@dpdk.org" <dev@dpdk.org>,
Ivan Malov <ivan.malov@arknetworks.am>
Subject: RE: [RFC] lib/ethdev: introduce table driven APIs
Date: Thu, 15 Jun 2023 07:42:12 +0000 [thread overview]
Message-ID: <DM4PR11MB5994A23456C1BBEB8253D2DFD75BA@DM4PR11MB5994.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CALBAE1N3irqKjd6Og46akS_uthKwu3ZfOTFF3Q_yoSRf3itksw@mail.gmail.com>
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Thursday, June 15, 2023 2:21 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: Ori Kam <orika@nvidia.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
>
> On Thu, Jun 15, 2023 at 11:33 AM Zhang, Qi Z <qi.z.zhang@intel.com> wrote:
> >
> > Hi Jerin:
>
> Hi Qi
>
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Thursday, June 15, 2023 12:58 PM
> > > To: Zhang, Qi Z <qi.z.zhang@intel.com>
> > > Cc: Ori Kam <orika@nvidia.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
> > >
> > > 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?
> >
> > 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.
next prev parent reply other threads:[~2023-06-15 7:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-12 11:15 Qi Zhang
2023-06-12 15:32 ` Ivan Malov
2023-06-13 3:48 ` Zhang, Qi Z
2023-06-13 6:38 ` Ivan Malov
2023-06-14 5:42 ` Zhang, Qi Z
2023-06-14 18:30 ` Ori Kam
2023-06-15 2:25 ` Zhang, Qi Z
2023-06-15 4:57 ` Jerin Jacob
2023-06-15 6:03 ` Zhang, Qi Z
2023-06-15 6:21 ` Jerin Jacob
2023-06-15 7:42 ` Zhang, Qi Z [this message]
2023-06-15 8:37 ` Jerin Jacob
2023-06-15 13:25 ` Zhang, Qi Z
2023-06-16 1:20 ` Jerin Jacob
2023-06-19 0:22 ` Zhang, Qi Z
2023-06-19 9:52 ` Jerin Jacob
2023-06-20 1:52 ` Zhang, Qi Z
2023-06-20 5:06 ` Jerin Jacob
2023-06-20 11:10 ` Ori Kam
2023-07-19 13:39 ` Dumitrescu, Cristian
2023-08-02 9:31 ` Dumitrescu, Cristian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DM4PR11MB5994A23456C1BBEB8253D2DFD75BA@DM4PR11MB5994.namprd11.prod.outlook.com \
--to=qi.z.zhang@intel.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=helin.zhang@intel.com \
--cc=ivan.malov@arknetworks.am \
--cc=jerinj@marvell.com \
--cc=jerinjacobk@gmail.com \
--cc=john.mcnamara@intel.com \
--cc=orika@nvidia.com \
--cc=techboard@dpdk.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).