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.
> >
> >
> > > >
> > > > > # 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.
> 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
> }
>
> 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.
>
> >
> > >
