Hi Andrew,
> -----Original Message----- > From: Andrew Rybchenko <arybche...@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 <or...@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. > >
