[v3] doc: update RSS action with best effort
diff mbox series

Message ID 1596776579-46445-1-git-send-email-orika@mellanox.com
State Superseded, archived
Delegated to: Thomas Monjalon
Headers show
Series
  • [v3] doc: update RSS action with best effort
Related show

Checks

Context Check Description
ci/travis-robot success Travis build: passed
ci/Intel-compilation success Compilation OK
ci/checkpatch success coding style OK

Commit Message

Ori Kam Aug. 7, 2020, 5:02 a.m. UTC
Using the rte_flow action RSS types field,
may result in 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, and will fail
in case the requested type is not supported.

Signed-off-by: Ori Kam <orika@mellanox.com>
---
v3:
 * Address ML comments.

v2:
 * Address ML comments.
---
 doc/guides/prog_guide/rte_flow.rst | 12 ++++++++++++
 1 file changed, 12 insertions(+)

Comments

Andrew Rybchenko Aug. 7, 2020, 9:41 a.m. UTC | #1
On 8/7/20 8:02 AM, Ori Kam wrote:
> Using the rte_flow action RSS types field,
> may result in 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, and will fail
> in case the requested type is not supported.
> 
> Signed-off-by: Ori Kam <orika@mellanox.com>
> ---
> v3:
>  * Address ML comments.
> 
> v2:
>  * Address ML comments.
> ---
>  doc/guides/prog_guide/rte_flow.rst | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 3e5cd1e..eada283 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1735,6 +1735,18 @@ 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.
>  
> +In case there are Non-applicable RSS types in the rule,
> +Best effort will be used.
> +This may be the result of:
> +
> +- Setting both UDP and TCP on the same rule.
> +
> +- Setting RSS types that don't match the requested pattern,
> +  for example, matching on UDP and hashing RSS on TCP.
> +
> +If requested RSS hash type is not supported in ``dev_info``.
> +The flow creation will fail.
> +

Consider:
If non-applicable for matching packets RSS types are requested,
these RSS types are simply ignored. For example, it happens if:

  - Hashing of both TCP and UDP ports is requested
    (only one can present in a packet).

  - Requested RSS types contradict to flow rule pattern
    (e.g. pattern has UDP item, but RSS types contain TCP).

If requested RSS types are not supported by the Ethernet device
at all (not reported in ``dev_info.flow_type_rss_offloads``),
the flow creation will fail.

>  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.
>
Ori Kam Aug. 10, 2020, 7:40 a.m. UTC | #2
Hi Andrew,


> -----Original Message-----
> From: Andrew Rybchenko <arybchenko@solarflare.com>
> 
> On 8/7/20 8:02 AM, Ori Kam wrote:
> > Using the rte_flow action RSS types field,
> > may result in 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, and will fail
> > in case the requested type is not supported.
> >
> > Signed-off-by: Ori Kam <orika@mellanox.com>
> > ---
> > v3:
> >  * Address ML comments.
> >
> > v2:
> >  * Address ML comments.
> > ---
> >  doc/guides/prog_guide/rte_flow.rst | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/doc/guides/prog_guide/rte_flow.rst
> b/doc/guides/prog_guide/rte_flow.rst
> > index 3e5cd1e..eada283 100644
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -1735,6 +1735,18 @@ 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.
> >
> > +In case there are Non-applicable RSS types in the rule,
> > +Best effort will be used.
> > +This may be the result of:
> > +
> > +- Setting both UDP and TCP on the same rule.
> > +
> > +- Setting RSS types that don't match the requested pattern,
> > +  for example, matching on UDP and hashing RSS on TCP.
> > +
> > +If requested RSS hash type is not supported in ``dev_info``.
> > +The flow creation will fail.
> > +
> 
> Consider:
> If non-applicable for matching packets RSS types are requested,
> these RSS types are simply ignored. For example, it happens if:
> 
>   - Hashing of both TCP and UDP ports is requested
>     (only one can present in a packet).
> 
>   - Requested RSS types contradict to flow rule pattern
>     (e.g. pattern has UDP item, but RSS types contain TCP).
> 
> If requested RSS types are not supported by the Ethernet device
> at all (not reported in ``dev_info.flow_type_rss_offloads``),
> the flow creation will fail.
> 
Sure sounds good, but since this is just copying your words, 
I will add your Signed-off-by to this patch, is that O.K?

> >  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.
> >
Andrew Rybchenko Aug. 10, 2020, 9:53 a.m. UTC | #3
On 8/10/20 10:40 AM, Ori Kam wrote:
> Hi Andrew,
>
>
>> -----Original Message-----
>> From: Andrew Rybchenko <arybchenko@solarflare.com>
>>
>> On 8/7/20 8:02 AM, Ori Kam wrote:
>>> Using the rte_flow action RSS types field,
>>> may result in 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, and will fail
>>> in case the requested type is not supported.
>>>
>>> Signed-off-by: Ori Kam <orika@mellanox.com>
>>> ---
>>> v3:
>>>  * Address ML comments.
>>>
>>> v2:
>>>  * Address ML comments.
>>> ---
>>>  doc/guides/prog_guide/rte_flow.rst | 12 ++++++++++++
>>>  1 file changed, 12 insertions(+)
>>>
>>> diff --git a/doc/guides/prog_guide/rte_flow.rst
>> b/doc/guides/prog_guide/rte_flow.rst
>>> index 3e5cd1e..eada283 100644
>>> --- a/doc/guides/prog_guide/rte_flow.rst
>>> +++ b/doc/guides/prog_guide/rte_flow.rst
>>> @@ -1735,6 +1735,18 @@ 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.
>>>
>>> +In case there are Non-applicable RSS types in the rule,
>>> +Best effort will be used.
>>> +This may be the result of:
>>> +
>>> +- Setting both UDP and TCP on the same rule.
>>> +
>>> +- Setting RSS types that don't match the requested pattern,
>>> +  for example, matching on UDP and hashing RSS on TCP.
>>> +
>>> +If requested RSS hash type is not supported in ``dev_info``.
>>> +The flow creation will fail.
>>> +
>> Consider:
>> If non-applicable for matching packets RSS types are requested,
>> these RSS types are simply ignored. For example, it happens if:
>>
>>   - Hashing of both TCP and UDP ports is requested
>>     (only one can present in a packet).
>>
>>   - Requested RSS types contradict to flow rule pattern
>>     (e.g. pattern has UDP item, but RSS types contain TCP).
>>
>> If requested RSS types are not supported by the Ethernet device
>> at all (not reported in ``dev_info.flow_type_rss_offloads``),
>> the flow creation will fail.
>>
> Sure sounds good, but since this is just copying your words, 
> I will add your Signed-off-by to this patch, is that O.K?

OK

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

Patch
diff mbox series

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 3e5cd1e..eada283 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1735,6 +1735,18 @@  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.
 
+In case there are Non-applicable RSS types in the rule,
+Best effort will be used.
+This may be the result of:
+
+- Setting both UDP and TCP on the same rule.
+
+- Setting RSS types that don't match the requested pattern,
+  for example, matching on UDP and hashing RSS on TCP.
+
+If requested RSS hash type is not supported in ``dev_info``.
+The flow creation will fail.
+
 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.