Re: [dpdk-dev] [PATCH] doc: update RSS action with best effort

[Andrew Rybchenko <arybchenko@solarflare.com>]

On 8/3/20 6:22 PM, Ori Kam wrote:
> Hi Andrew,
>
>> -----Original Message-----
>> From: Andrew Rybchenko <arybchenko@solarflare.com>
>>
>> On 8/3/20 5:28 PM, Ori Kam wrote:
>>> Using the rte_flow action RSS types field,
>>> may result in an undefined outcome.
>>>
>>> For example selecting both UDP and TCP,
>>> selecting TCP RSS type but the pattern is targeting UDP traffic.
>>> another option is that the PMD doesn't support all requested types.
>>>
>>> Until now, it wasn't clear what will happen in such cases.
>>> This commit clarify this issue by stating that the PMD
>>> will work in the best-effort mode.
>>>
>>> Signed-off-by: Ori Kam <orika@mellanox.com>
>>> ---
>>>  doc/guides/prog_guide/rte_flow.rst | 10 ++++++++++
>>>  1 file changed, 10 insertions(+)
>>>
>>> diff --git a/doc/guides/prog_guide/rte_flow.rst
>> b/doc/guides/prog_guide/rte_flow.rst
>>> index 3e5cd1e..d000560 100644
>>> --- a/doc/guides/prog_guide/rte_flow.rst
>>> +++ b/doc/guides/prog_guide/rte_flow.rst
>>> @@ -1735,6 +1735,16 @@ unspecified "best-effort" settings from the
>> underlying PMD, which depending
>>>  on the flow rule, may result in anything ranging from empty (single queue)
>>>  to all-inclusive RSS.
>>>
>>> +Best effort will be used, in case there is a conflict inside the rule.
>>> +The conflict can be the result of:
>>> +
>>> +- Conflicting RSS types, for example setting both UDP and TCP.
>>> +
>>> +- Conflicting between RSS types and the requested pattern to match,
>>> +  for example matching on UDP and hashing RSS on TCP.
>> IMHO it is not a problem at all, but good to clarify anyway.
>>
> Agree this patch is just for clarification.
>
>>> +
>>> +- Hashing on types that are not supported by the PMD.
>> Shouldn't it return error to the caller?
>>
> That’s depends, if for example the application requested eth and IPv4,
> and the PMD can do only IPv4 so according to this, the PMD will just do IPv4.

I think it is a bad behaviour. Application has required information to
provide correct parameters and therefore incorrect should be rejected.
Am I missing something?

>>> +
>>>  Note: RSS hash result is stored in the ``hash.rss`` mbuf field which
>>>  overlaps ``hash.fdir.lo``. Since `Action: MARK`_ sets the ``hash.fdir.hi``
>>>  field only, both can be requested simultaneously.
>>>