> -----Original Message-----
> From: Ferruh Yigit <ferruh.yi...@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 <or...@nvidia.com> wrote:
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Jerin Jacob <jerinjac...@gmail.com>
> >>> Sent: Friday, September 1, 2023 5:07 AM
> >>>
> >>> On Thu, Aug 31, 2023 at 4:02 PM Ori Kam <or...@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
