DPDK patches and discussions
 help / color / mirror / Atom feed
From: Andrew Rybchenko <arybchenko@solarflare.com>
To: Ori Kam <orika@mellanox.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	"John McNamara" <john.mcnamara@intel.com>,
	Marko Kovacevic <marko.kovacevic@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] doc: update RSS action with best effort
Date: Mon, 3 Aug 2020 19:03:53 +0300
Message-ID: <26fef732-536a-cf71-6948-d35feff4220a@solarflare.com> (raw)
In-Reply-To: <AM6PR05MB5176C159C1701D00702464F6DB4D0@AM6PR05MB5176.eurprd05.prod.outlook.com>

On 8/3/20 6:47 PM, Ori Kam wrote:
> 
> 
>> -----Original Message-----
>> From: 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?
>>
> In RTE flow you can't know what are the parameters that are supported.
> One option is to fail the rule, but this means failing the rule even if some of them are supported.
> Or we can choose to fail if all the types are unsupported, but this will result in miss match between
> adding two types and adding just one type. For example the PMD doesn't support RSS on eth
> and the application request RSS on ETH and IPv4 so the PMD will do IPv4 RSS,
> while if the user selects only ETH the rule will fail.
> Same this is exactly the same case as miss match the application requests something
> that the PMD can't supply. 
> In any case I think this is the current behavior of the PMD so this just clarify it.

I'm sorry, but the PMD is hardly applicable here.
Do you mean the "mlx5" PMD? Or have you reviewed all PMDs?

No I understand that the topic is more complicated, but
covering complex cases should not spoil simple.
I think that information provided in dev_info should
specify all supported protocols/fields.
Yes, it is acceptable to behave best effort if requested
field is supported in general, but it not for the flow.
Please, make it a bit clearer in the suggested description.

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


  reply	other threads:[~2020-08-03 16:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03 14:28 Ori Kam
2020-08-03 14:33 ` Andrew Rybchenko
2020-08-03 15:22   ` Ori Kam
2020-08-03 15:33     ` Andrew Rybchenko
2020-08-03 15:47       ` Ori Kam
2020-08-03 16:03         ` Andrew Rybchenko [this message]
2020-08-03 16:53           ` Ori Kam
2020-08-03 15:40     ` David Marchand
2020-08-03 15:49       ` Ori Kam
2020-08-03 15:55         ` Andrew Rybchenko
2020-08-03 16:12           ` Thomas Monjalon
2020-09-14 14:29           ` Ferruh Yigit
2020-08-04  8:13 ` [dpdk-dev] [PATCH v2] " Ori Kam
2020-08-05 12:39   ` Ori Kam
2020-08-05 13:39   ` Andrew Rybchenko
2020-08-05 14:08     ` Ori Kam
2020-08-06 12:14       ` Andrew Rybchenko
2020-08-06 16:55         ` Ori Kam
2020-09-14 14:38       ` Ferruh Yigit
2020-08-07  5:02 ` [dpdk-dev] [PATCH v3] " Ori Kam
2020-08-07  9:41   ` Andrew Rybchenko
2020-08-10  7:40     ` Ori Kam
2020-08-10  9:53       ` Andrew Rybchenko
2020-08-10 15:08 ` [dpdk-dev] [PATCH v4] " Ori Kam
2020-09-14 14:43   ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=26fef732-536a-cf71-6948-d35feff4220a@solarflare.com \
    --to=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=john.mcnamara@intel.com \
    --cc=marko.kovacevic@intel.com \
    --cc=orika@mellanox.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git