From: Ori Kam <orika@nvidia.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>, Jerin Jacob <jerinjacobk@gmail.com>
Cc: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>,
"Morten Brørup" <mb@smartsharesystems.com>,
"Zhang, Qi Z" <qi.z.zhang@intel.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>,
"techboard@dpdk.org" <techboard@dpdk.org>,
"Mcnamara, John" <john.mcnamara@intel.com>,
"Zhang, Helin" <helin.zhang@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: RE: DPDK community: RTE_FLOW support for P4-programmable devices
Date: Wed, 6 Sep 2023 08:30:54 +0000 [thread overview]
Message-ID: <MW2PR12MB46669A14A21981F267111DD4D6EFA@MW2PR12MB4666.namprd12.prod.outlook.com> (raw)
In-Reply-To: <d23487d0-ffdd-74ca-9458-dec4973a9ef3@amd.com>
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@amd.com>
> Sent: Monday, September 4, 2023 10:46 AM
>
> On 9/1/2023 10:52 AM, Jerin Jacob wrote:
> > On Fri, Sep 1, 2023 at 12:27 PM Ori Kam <orika@nvidia.com> wrote:
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Jerin Jacob <jerinjacobk@gmail.com>
> >>> Sent: Friday, September 1, 2023 5:07 AM
> >>>
> >>> On Thu, Aug 31, 2023 at 4:02 PM Ori Kam <orika@nvidia.com> wrote:
> >>>>
> >>>> Hi
> >>>
> >>>>>>>
> >>>>>>> 3. Everybody on the call agreed that the P4-programmable devices
> from
> >>>>> Intel,
> >>>>>>> AMD and others need to be fully supported by DPDK and that there are
> >>>>> some
> >>>>>>> gaps in RTE_FLOW to be fixed for supporting these devices.
> >>>>>>
> >>>>>> Personally, It makes sense to me to have normative DPDK API to send
> p4
> >>>>>> runtime message to the
> >>>>>> ethdev so that we have "vendor neutral + DPDK based" p4 runtime
> >>> backend.
> >>>>>>
> >>>>>> I prefer to have specialized ethdev ops for this due to the following
> >>> reasons.
> >>>>>>
> >>>>>> # If the ethdev has both real TCAM based HW(for existing rte_flow
> >>>>>> patterns and actions) and SW agent to receive P4 runtime message etc.
> >>>>>> Typically, it needs to take a different path in driver to talk. Assume, if
> you
> >>>>>> have cascaded patterns/actions, One is targeted for TCAM and other for
> >>>>>> SW agent for p4, one
> >>>>>> need to have serious amount checking for dispatching.It complicates
> >>>>>> the driver and forbid to have
> >>>>>> driver optimization especially cases for templates etc. if user making
> >>>>>> rules for both category of HW.
> >>>>>>
> >>>>>
> >>>>> Indeed I am not against dedicated APIs for P4 runtime backend.
> >>>>>
> >>>>> But assuming there is a dedicated rte_flow item for P4, how it is
> >>>>> different than dedicated API in above scenario?
> >>>>> If driver detects P4 runtime specific rule, it can bail it out to SW agent.
> >>>>> Can you please elaborate the complexity it introduces?
> >>>
> >>> Assume, normal existing rte-flow programming include a bunch of
> >>> register writes and
> >>> p4 runtime backend is more of SW ring. If a template has both patterns
> >>> and actions
> >>> as cascaded, it will be difficult for driver to optimize the template.
> >>>
>
> I assumed P4 specific item/action can take completely separate path, do
> you think existing rte_flow item/actions and P4 item/actions can mix in
> same rte_flow rule?
>
I don't think one rule will use both APIs
>
> >>>
> >>>>>
> >>>>>> # All we need "char buffer//string" based communication ethdev <->
> app.
> >>>>>>
> >>>>>
> >>>>> Yes, and both a dedicated API or dedicated rte_flow item can provide
> >>>>> medium for this communication.
> >>>>>
> >>>>> rte_flow one has flexibility & extensibility advantages, but maybe not
> >>>>> as straightforward as an API.
> >>>>
> >>>> I think not using the rte_flow will also require duplication of all the rule
> >>> handling functions and table creations, for example aync rule
> create/destroy
> >>> query ......
> >>>
> >>> Yes. That is a fair point. I am OK with exposing as rte_flow.
> >>> As a driver implementation note, to get rid of the above problem,
> >>> driver can choose to have pseudo ethdev devices for p4 if needed(if
> >>> driver finds difficult to combine TCAM based on HW rules and p4
> >>> runtime rule).
> >>>
> >>
> >> What about the following concept:
> >> The p4 compiler can generate the translation to known PMD objects in
> rte_flow,
> >> then when a command is sent from the p4 agent to the offload using GRPC or
> any other way, the DPDK will convert from
> >> p4 protocol to rte_flow commands (this should be very fast since the
> commands are known and the mapping is already
> >> defined).
> >>
> >> To support the above idea we need to add two new functions to rte_flow
> (each function will be implemented in PMD level)
> >
> > If the implemention of rte_flow_p4_runtime((p4 command based on the p4
> spec))
> > is defined in PMD level, The PMD driver to decide to use rte_flow or
> > something else.
> > I think it is good, this is actually going back to specialized API.
> > BTW, rte_flow prefix is not needed in that case.
> >
>
> +1 this is leaning to the dedicated API option.
I agree that we need some dedicated API but it is very lean,
and doesn't have any duplication with rte_flow.
In my viewpoint there are only the two suggested functions,
I don't want to see a function to insert rules or new items/actions.
In other words, it is only 2 more functions and not a new lib.
One more thing ideally the complier output format will be in rte_flow format,
And the about function are only for the grpc interface.
>
> >
> >
> >> Rte_flow_register_p4(void *p4_info, void *p4_blob)
> >> {
> >> Creates the static structures/objects
> >> Internal register the p4 commands to PMD translation table.
> >> }
> >>
> >> Rte_flow_p4_runtime(p4 command based on the p4 spec)
> >> {
> >> Based on the registered mapping, translate the command to rte_flow
> commands.
> >> Rte_flow_xxx() calls
>
> For the 'rte_flow_xxx()' calls here, my understanding is existing
> rte_flow calls are not sufficient to meet the requirement to program the
> P4 pipeline, that is why this patch is about defining the new flow item.
>
I think rte_flow is good and doesn’t miss much,
I will be more than happy to see what is missing and add it. We have a complete session about it
in the summit.
Saying that PMD can do whatever it wants internally.
> If these are not rte_flow calls but PMD defined code, than it is not
> much different from previously suggested dedicated API solution.
>
I agree, this is much closer to the original suggestion,
I think the correct way is that the compiler will output rte_flow
structures.
This was my original thinking and I still think this is the best one.
And if something is missing in rte_flow we need to add it.
>
> >> }
> >>
> >> As far as I see, the above code will also allow PMD to implement internal
> logic if needed, while from DPDK API,
> >> we will only add two new functions.
> >>
> >>>
> >>>>
Best,
Ori
next prev parent reply other threads:[~2023-09-06 8:30 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-02 17:34 [PATCH] ethdev: introduce generic flow item and action Qi Zhang
2023-08-02 9:37 ` Zhang, Qi Z
2023-08-02 10:25 ` Morten Brørup
2023-08-02 11:01 ` Morten Brørup
2023-08-02 11:21 ` Jerin Jacob
2023-08-02 14:06 ` Dumitrescu, Cristian
2023-08-02 15:24 ` Morten Brørup
2023-08-02 15:47 ` Ori Kam
2023-08-02 16:06 ` Ori Kam
2023-08-02 17:22 ` Dumitrescu, Cristian
2023-08-02 17:56 ` Morten Brørup
2023-08-03 1:05 ` Zhang, Qi Z
2023-08-03 13:57 ` Morten Brørup
2023-08-16 13:23 ` Dumitrescu, Cristian
2023-08-16 14:20 ` Morten Brørup
2023-08-16 17:08 ` Ferruh Yigit
2023-08-16 17:18 ` Dumitrescu, Cristian
2023-08-16 16:19 ` DPDK community: RTE_FLOW support for P4-programmable devices Dumitrescu, Cristian
2023-08-27 7:48 ` Ori Kam
2023-08-28 16:12 ` Dumitrescu, Cristian
2023-08-29 7:38 ` Jerin Jacob
2023-08-29 10:18 ` Ferruh Yigit
2023-08-31 10:32 ` Ori Kam
2023-08-31 13:42 ` Stephen Hemminger
2023-09-01 2:07 ` Jerin Jacob
2023-09-01 6:57 ` Ori Kam
2023-09-01 9:52 ` Jerin Jacob
2023-09-04 7:45 ` Ferruh Yigit
2023-09-06 8:30 ` Ori Kam [this message]
2023-09-11 20:20 ` Dumitrescu, Cristian
2023-08-02 16:56 ` [PATCH] ethdev: introduce generic flow item and action Dumitrescu, Cristian
2023-08-03 8:39 ` Ori Kam
2023-08-16 13:12 ` Dumitrescu, Cristian
2023-08-02 16:14 ` Dumitrescu, Cristian
2023-08-02 14:06 ` Dumitrescu, Cristian
2023-08-02 14:54 ` Morten Brørup
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=MW2PR12MB46669A14A21981F267111DD4D6EFA@MW2PR12MB4666.namprd12.prod.outlook.com \
--to=orika@nvidia.com \
--cc=bruce.richardson@intel.com \
--cc=cristian.dumitrescu@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=helin.zhang@intel.com \
--cc=jerinj@marvell.com \
--cc=jerinjacobk@gmail.com \
--cc=john.mcnamara@intel.com \
--cc=mb@smartsharesystems.com \
--cc=qi.z.zhang@intel.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).