All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
To: Shahaf Shuler <shahafs@mellanox.com>
Cc: Ori Kam <orika@mellanox.com>, Ophir Munk <ophirmu@mellanox.com>,
	Yongseok Koh <yskoh@mellanox.com>,
	Andrew Rybchenko <arybchenko@solarflare.com>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	Thomas Monjalon <thomas@monjalon.net>,
	Asaf Penso <asafp@mellanox.com>, Olga Shern <olgas@mellanox.com>
Subject: Re: [PATCH v2] ethdev: document RSS default key and types
Date: Wed, 14 Nov 2018 10:40:40 +0100	[thread overview]
Message-ID: <20181114094040.GG17131@6wind.com> (raw)
In-Reply-To: <DB7PR05MB44269AD5C76C904403354211C3C20@DB7PR05MB4426.eurprd05.prod.outlook.com>

Hi Shahaf,

On Tue, Nov 13, 2018 at 06:39:04PM +0000, Shahaf Shuler wrote:
> Hi Adrien, 
> 
> Tuesday, November 13, 2018 7:15 PM, Adrien Mazarguil:
> > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: document RSS default key and
> > types
> > 
> > Again a bit late to the party, please see below.
> > 
> > On Sun, Nov 11, 2018 at 09:35:22AM +0000, Ori Kam wrote:
> 
> [...]
> 
> > > > The setfault is the result of commit a4391f8bae ("app/testpmd: set
> > > > default RSS key as null").
> > > > Reverting this commit should fix the segfault but it also means
> > > > there is no way to set default key (key=NULL) with testpmd.
> > > > Need to check if this is only a testpmd limitation and not all
> > > > applications limitation.
> > > >
> > > > We should decide how an application can set default RSS without
> > > > knowing anything about keys.
> > > >
> > >
> > > I agree with Adrian that the main criteria should be the length.
> > > Maybe the set default RSS in testpmd should get new parameter.
> > 
> > Since [1] was reverted and we seem to agree that a zero key_len should
> > trigger a PMD-specific default key, this can already be requested with
> > testpmd by overriding key_len, e.g.:
> > 
> >  flow create 1 pattern eth / end actions rss key_len 0 / end
> > 
> > Using an empty string as the key would yield the same result but cannot be
> > expressed on the command line yet. Note that specifying a key automatically
> > overrides key_len, so key_len must be forced to 0 last to get PMD defaults:
> > 
> >  flow create 1 pattern eth / end actions rss key foo key_len 0 / end
> 
> I don't understand why we are backing up API claims with "how testpmd is implemented". The APIs should be correct, regardless of how testpmd is using them. 

This wasn't the intent, I mean, currently one cannot input something like
that to get a zero key length:

 flow create 1 pattern eth / end actions rss key "" / end

Because "" is interpreted literally. So the only way to request a zero key
length is by explicitly setting it through "key_len 0".

The API remains clear: a zero key length requests default behavior from the
PMD regardless of the key pointer, which doesn't *have* to be NULL, merely
undefined. Testpmd does exactly that.

> To this doc issue, 
> I don't understand on what cases it makes sense for application to have rss_key_len = 0 while rss_key != NULL. This is obviously in-consist input, and of course all PMD will just ignore the key.
> I think enforcing rss_key and rss_key_len to be NULL is a fair requirement from application, and it makes no confusion in the API inputs.

Then you need to define what happens when key_len != 0 and key == NULL, also
when key_len == 0 and key != NULL, none of which make sense currently.

There's no reason for the PMD to even look at the key pointer if key_len is
0. Only if nonzero, it *can* check for its validity however there's no
reason to, it's a programming error in the application if not the case.
assert() is more appropriate for such situations.

I agree there's a lack of documentation which must be addressed, my point is
that key_len is the only guarantee a PMD needs from the application.

> > Here key_len is set to testpmd's default size when parsing "rss", updated to
> > 3 when parsing "key foo" and updated once again when parsing "key_len 0".
> > 
> > Lastly, while it would make sense for testpmd to use 0 as the default value,
> > doing so yields inconsistent balancing results between vendors/devices as
> > they all come with a different key. Same reason as initializing the RSS types
> > field to the global rss_hf instead of 0.
> 
> 
> 
> > 
> > [1] "app/testpmd: revert setting default RSS"
> > 
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> > ils.dpdk.org%2Farchives%2Fdev%2F2018-
> > November%2F118786.html&amp;data=02%7C01%7Cshahafs%40mellanox.co
> > m%7C0eecf3e9af4b4b6bc53108d6498ba2a8%7Ca652971c7d2e4d9ba6a4d1492
> > 56f461b%7C0%7C0%7C636777261425388073&amp;sdata=Hu0iGr2xS%2FI%2FI
> > s5PtzCylMMft5w5TBmtd3GYppEKKcA%3D&amp;reserved=0

-- 
Adrien Mazarguil
6WIND

  reply	other threads:[~2018-11-14  9:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-03 15:46 [PATCH v1] ethdev: document RSS default key and types Ophir Munk
2018-11-05 13:11 ` Ferruh Yigit
2018-11-05 21:47 ` Thomas Monjalon
2018-11-07  9:23 ` [PATCH v2] " Ophir Munk
2018-11-07  9:31   ` Adrien Mazarguil
2018-11-07 12:39     ` Ophir Munk
2018-11-07 14:06       ` Adrien Mazarguil
2018-11-07 15:13         ` Ophir Munk
2018-11-07 16:41           ` Adrien Mazarguil
2018-11-08  6:32             ` Andrew Rybchenko
2018-11-08  8:50             ` Ophir Munk
2018-11-08 23:07               ` Yongseok Koh
2018-11-09  8:13                 ` Ophir Munk
2018-11-11  9:35                   ` Ori Kam
2018-11-13 17:15                     ` Adrien Mazarguil
2018-11-13 18:04                       ` Ophir Munk
2018-11-13 18:39                       ` Shahaf Shuler
2018-11-14  9:40                         ` Adrien Mazarguil [this message]
2018-11-14 13:51                           ` Shahaf Shuler
2018-11-14 15:16                             ` Adrien Mazarguil

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=20181114094040.GG17131@6wind.com \
    --to=adrien.mazarguil@6wind.com \
    --cc=arybchenko@solarflare.com \
    --cc=asafp@mellanox.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=olgas@mellanox.com \
    --cc=ophirmu@mellanox.com \
    --cc=orika@mellanox.com \
    --cc=shahafs@mellanox.com \
    --cc=thomas@monjalon.net \
    --cc=yskoh@mellanox.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.