[dpdk-dev] a doubt about rss types action in rte_flow

[dpdk-dev] a doubt about rss types action in rte_flow

[Peng, Yuan]

Hi Adrien,

I have a doubt about the action rss types in rte_flow.
testpmd> flow create 0 ingress pattern end actions rss types end / end

what is the expected function of the command?
Does it mean enable RSS in no types? So actually it can disable rss all?

There are different execution result of the command from our different NICs.
Some NICs report error:
Caught error type 2 (flow rule (handle)): Failed to create flow.: Invalid argument
With some NICs, the command can be executed successfully, and disable rss function for all packet types.

Could you help to solve my questions?

Thank you.
Yuan.

Re: [dpdk-dev] a doubt about rss types action in rte_flow

[Adrien Mazarguil]

Hi and sorry for the delay.

On Thu, Oct 18, 2018 at 06:42:52AM +0000, Peng, Yuan wrote:
> Hi Adrien,
> 
> I have a doubt about the action rss types in rte_flow.
> testpmd> flow create 0 ingress pattern end actions rss types end / end
> 
> what is the expected function of the command?
> Does it mean enable RSS in no types? So actually it can disable rss all?

Doing so requests whatever counts as default RSS from the driver as
documented in doc/guides/prog_guide/rte_flow.rst:

 "Unlike global RSS settings used by other DPDK APIs, unsetting the ``types``
  field does not disable RSS in a flow rule. Doing so instead requests safe
  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."

> There are different execution result of the command from our different NICs.
> Some NICs report error:
> Caught error type 2 (flow rule (handle)): Failed to create flow.: Invalid argument
> With some NICs, the command can be executed successfully, and disable rss function for all packet types.
> 
> Could you help to solve my questions?

PMDs must handle it as described by the documentation, 0 being the only safe
value applications can rely on regardless of device properties; applications
that just want traffic to be spread somehow among the queues they configured
instead of a single queue.

Therefore PMDs that currently reject it should be fixed.

-- 
Adrien Mazarguil
6WIND