Re: [dpdk-dev] [PATCH 1/2] ethdev: add flow action type update as an offload

[Ori Kam <orika@mellanox.com>]

> -----Original Message-----
> From: Andrew Rybchenko <arybchenko@solarflare.com>
> Sent: Wednesday, November 6, 2019 8:41 AM
> To: Ori Kam <orika@mellanox.com>; Thomas Monjalon
> <thomas@monjalon.net>
> Cc: dev@dpdk.org; pbhagavatula@marvell.com; ferruh.yigit@intel.com;
> jerinj@marvell.com; John McNamara <john.mcnamara@intel.com>; Marko
> Kovacevic <marko.kovacevic@intel.com>; Adrien Mazarguil
> <adrien.mazarguil@6wind.com>; david.marchand@redhat.com;
> ktraynor@redhat.com
> Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add flow action type update as an
> offload
> 
> On 11/5/19 7:37 PM, Ori Kam wrote:
> >
> >
> >> -----Original Message-----
> >> From: Andrew Rybchenko <arybchenko@solarflare.com>
> >> Sent: Tuesday, November 5, 2019 1:31 PM
> >> To: Ori Kam <orika@mellanox.com>; Thomas Monjalon
> >> <thomas@monjalon.net>
> >> Cc: dev@dpdk.org; pbhagavatula@marvell.com; ferruh.yigit@intel.com;
> >> jerinj@marvell.com; John McNamara <john.mcnamara@intel.com>; Marko
> >> Kovacevic <marko.kovacevic@intel.com>; Adrien Mazarguil
> >> <adrien.mazarguil@6wind.com>; david.marchand@redhat.com;
> >> ktraynor@redhat.com
> >> Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add flow action type update as
> an
> >> offload
> >>
> >
> > [Snip]
> >
> >>>
> >>> Yes but like I said in Mellanox PMD for example we supported the mark
> only
> >> on non-transfer flows until this release.
> >>> so when the user set mark on transfer flow it was invalid. (in transfer flow
> if
> >> we have a miss we send the packet back to the Rx
> >>> port so the application can understand on which table the miss happened)
> >>> In this version we added the support for mark also in transfer (E-Switch)
> >> flows.
> >>> So my question before this release what should the PMD report? What
> should
> >> the PMD report after this release?
> >>>
> >>> Your idea was our first thought when adding the Tx meta, in that case the
> >> meta was always set in application
> >>> so we thought that this offload will enable us better function selection, but
> as
> >> you know we removed this capability
> >>> since it is not correct any more.
> >>>
> >>>
> >>>
> >>>> The above also highlights problems of the meta vs mark design. They are
> >> very
> >>>> similar and there is no any good definition of the difference and rules
> >>>> which
> >>>> one should be used/supported in which conditions.
> >>>>
> >>>
> >>> Mark and Meta are exactly the same, the meta is just another value that
> the
> >> application can use.
> >>> This is why both should act the same.
> >>>
> >>> And maybe this is the wining argument, the rte_flow validation approach
> was
> >> used and accepted for the meta.
> >>> So lets try it also with the mark. (please also remember that we didn't have
> >> this mark until now to somehow the
> >>> PMD worked 😊)
> >>>
> >>> Like I said before, I understand your approach, and each one of them has
> its
> >> own advantages and draw backs.
> >>> Lets start using the rte_flow approach and see how it goes, I promise you
> that
> >> if I see that it doesn't scale or cause more
> >>> issues I will be first one to submit changes.
> >>
> >> I tend to say OK, let's try. However, it must be documented
> >> in MARK action that if an application wants to use it, a rule
> >> with the action must be validated before device start.
> >
> > I agree to add this to the rte_flow mark action documation.
> >
> >> PMD may use the attempt as an indication from the application
> >> that it would like to use flow mark even if the validation
> >> fails.
> >
> > No if the PMD uses this validation as hint it should return success and
> > use the correct PMD.
> 
> It would make it too strictly dependent on pattern/actions/state.

I'm not sure I understand your comment.
Why would it make it to strict? I guess that mark action is doesn't care which items are in 
the flow, so just setting eth item sound good enough.
Also I guess the mark doesn't conflict with many actions maybe the meta.
So the application doesn't have a lot of choices.
In any case and this is the most important one. In any case the application must validate that the 
Nic support the mark in any case, according to RTE_FLOW definition. What is the meaning
of saying we support offload (using your segguetion) and then each flow you try to insert
will fail. So in any case the application must validate the flows it is going to use.

> 
> >> Ori, please, suggest formalized pattern and actions
> >> specification to use if application wants to utilize
> >> validation result as a criteria to enable/disable flow
> >> marks usage.
> >
> > I can’t do that, it depends on the application, the most basic is just "pattern
> eth actions mark / queue" .
> > In some cases where you need it for E-Switch if should be something like
> "transfer  items port / eth / actions mark"
> 
> If so, what application author should do if even maintainers cannot
> formalize it. It sounds like the approach does not work.

This should be very easy for the application to know. How can I a mantianer know 
what flows and what is important to the application, I need to make sure that the application
can understand if what it wants is supported.

> 
> >> What should be done if patterns to use and set
> >> of actions together with MARK are not known in advance.
> >
> > I think that the application knows which kind of traffic it expects and which
> actions it needs.
> 
> I'm afraid it is not always true.
> 

Can you please give me such example, how can you develop an application without knowing what it should do?
This means the application is not optimized and impossible to test.

> >> Andrew.
> >
> > Ori
> >

Ori