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

[Ori Kam]

> -----Original Message-----
> From: Andrew Rybchenko <arybchenko at solarflare.com>
> Sent: Tuesday, November 5, 2019 1:31 PM
> To: Ori Kam <orika at mellanox.com>; Thomas Monjalon
> <thomas at monjalon.net>
> Cc: dev at dpdk.org; pbhagavatula at marvell.com; ferruh.yigit at intel.com;
> jerinj at marvell.com; John McNamara <john.mcnamara at intel.com>; Marko
> Kovacevic <marko.kovacevic at intel.com>; Adrien Mazarguil
> <adrien.mazarguil at 6wind.com>; david.marchand at redhat.com;
> ktraynor at 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.

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"

> 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.
 
> Andrew.

Ori