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 <or...@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. > + > +- Hashing on types that are not supported by the PMD. Shouldn't it return error to the caller? > + > 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. >
