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

[Andrew Rybchenko]

On 11/5/19 7:37 PM, Ori Kam wrote:
> 
> 
>> -----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.

It would make it too strictly dependent on pattern/actions/state.

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

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

>> Andrew.
> 
> Ori
>