From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150042.outbound.protection.outlook.com [40.107.15.42]) by dpdk.org (Postfix) with ESMTP id 335527CE2 for ; Wed, 14 Nov 2018 14:51:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OnhqjS2zxo6oNot+h2W7mDixh2X6gsTHWnTerflO8Fw=; b=tEFlJycXeaNeinJcqaC8QUKItlhjam/eQjRal5q/FKZeTPJ1S4pA5JjmjiOmaXTN+Y4K0x5fCRd5J1nowKhA9TaEEr3h0Ep67gTobXP/P9F9wVT6MmkFHposPpPJtQPUNd0vp3/Uimlu+mUG9xcw2J0yeB/iVePNtDlgKlrlMig= Received: from DB7PR05MB4426.eurprd05.prod.outlook.com (52.134.109.15) by DB7PR05MB5100.eurprd05.prod.outlook.com (20.176.237.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.27; Wed, 14 Nov 2018 13:51:19 +0000 Received: from DB7PR05MB4426.eurprd05.prod.outlook.com ([fe80::bc22:c2f5:208d:826f]) by DB7PR05MB4426.eurprd05.prod.outlook.com ([fe80::bc22:c2f5:208d:826f%2]) with mapi id 15.20.1294.044; Wed, 14 Nov 2018 13:51:19 +0000 From: Shahaf Shuler To: Adrien Mazarguil CC: Ori Kam , Ophir Munk , Yongseok Koh , Andrew Rybchenko , Ferruh Yigit , "dev@dpdk.org" , Thomas Monjalon , Asaf Penso , Olga Shern Thread-Topic: [dpdk-dev] [PATCH v2] ethdev: document RSS default key and types Thread-Index: AQHUdnuTzEeEC1WTSkenbNxbXJIGnKVEDEOAgAA0mQCAABg3AIAAEryAgAAYpICAAQ60AIAA73+AgACYpgCAAzt4AIADpSyAgAAU3sCAAP5wAIAANt3g Date: Wed, 14 Nov 2018 13:51:19 +0000 Message-ID: References: <20181107140604.GL4638@6wind.com> <20181107164118.GM4638@6wind.com> <20181113171519.GF17131@6wind.com> <20181114094040.GG17131@6wind.com> In-Reply-To: <20181114094040.GG17131@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=shahafs@mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR05MB5100; 6:jSeqKwuyi2O/usbyY5sNWAyzjFzT6+79YY/dRmMnkMC8M3BScQgzI4+SB1bu1Yu2JeMzWmDGHFS4Wlp2DKv1vqFdoFR/kIT0wrVWHSicuJmH30RWnCmAF6JaozogSx8Bs9l8I2WnVTqjPe/zDxtg9pSap70Fi/ck1bSpYEiSxS6cosMiptzdPnMNPKjSAqkdBJzy+c/quUF9FYHi7Mi5kgAli+KFb9FN+RSQbqpa6uZl0zXo/2q/LntQiUMnpvuYGLIS+yGERAz0Ba/QMmBPHSoLogw82eVE34Jk5NJckQfHco9YKKX7Y01Lemp1c4R4r947gSBf3iKpBcdGScTO3085NTco3W6/Lu0jA6XoAI3CAPtEa7hX17nFKssjPYmpq3YKlLlMpbPn8KPcyfAqLKSF2xZJpd9OvcMrw+WNbX1kztjMq7Un1xo3ETudzTNHOEpupNGuzQazO1c3gKtPEw==; 5:kZevrt/YtG4Iaebc6A9zF+K6okYdyaFFgSwCpJMlqLoNfJAA7n4VYblSRemiiwngmmaNuJYCK8i0qR3GNJFMk6/G13eXvGZuTO9VO0QyNLL14oJSvdIOb9shZmrGCuBGjr9Icm1Q9i8aYbE3s9FP0dMfCDWOaX9KyudhVlk1dNU=; 7:nbUUalZqQpfpeUkmM5EjUP88vlCkCDk9s2otWS2MOwBmcXeQpLa3kJF5ilKUjGLsurbyZ7OIARnuy1ItRDFGuXl9nJY9XNt5o+i9Aqou49wh1L1t/ChbiM/4PXEPvBZPqNjb+Xq/lHw7B/HlNMLKfg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 377ae9e9-47c5-4e75-88b2-08d64a3841a8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DB7PR05MB5100; x-ms-traffictypediagnostic: DB7PR05MB5100: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(100405760836317)(45079756050767)(189930954265078); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231410)(944501410)(52105112)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:DB7PR05MB5100; BCL:0; PCL:0; RULEID:; SRVR:DB7PR05MB5100; x-forefront-prvs: 085634EFF4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(39860400002)(396003)(366004)(346002)(199004)(189003)(3846002)(6116002)(106356001)(93886005)(102836004)(316002)(105586002)(81166006)(966005)(66066001)(14454004)(186003)(8676002)(76176011)(81156014)(575784001)(7696005)(86362001)(2900100001)(476003)(25786009)(11346002)(486006)(8936002)(26005)(97736004)(54906003)(99286004)(446003)(6506007)(256004)(14444005)(6916009)(68736007)(5660300001)(45080400002)(4326008)(478600001)(55016002)(2906002)(229853002)(74316002)(305945005)(6436002)(9686003)(6246003)(6306002)(7736002)(107886003)(33656002)(71190400001)(71200400001)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR05MB5100; H:DB7PR05MB4426.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: fBj7LUiObcnuWTURZY5NOX25Zpwr7yWu5k6qaHqpYnBdWATP6k4d6FE97U+6LjRBOQk83C1oUlam6IY2pARQeqHy4QhGMxHQYSYkZ3G3L8Ck4WnH/LoqYY4OVO92S+/IaZy+I63A0gbDVaaFX0j/UPSyrBCTZ7F8fwvoW5UzuP2Uo3rjyVPKmFPJZrhmyxWUNeE1ZAs8OwpfojsPjWgvXUVW9FA5RoBycbMWISZBHRIegig7xT73qAUzZcOHcVSRzyGQHHlcJjJwGcZvh0wmlz9tbtfFogw1rZoUNmPdbhzb8rqcnXtqqKFjxbjV67M3XRYw5XHMDwZ2lmY5U+fP0qyenDjiW8W6N9KSjnrr/8Q= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 377ae9e9-47c5-4e75-88b2-08d64a3841a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2018 13:51:19.8285 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR05MB5100 Subject: Re: [dpdk-dev] [PATCH v2] ethdev: document RSS default key and types X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 13:51:22 -0000 Wednesday, November 14, 2018 11:41 AM, Adrien Mazarguil: > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: document RSS default key and > types >=20 > Hi Shahaf, >=20 > 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=3DNULL) 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 l= ast > 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 i= s > implemented". The APIs should be correct, regardless of how testpmd is > using them. >=20 > This wasn't the intent, I mean, currently one cannot input something like= that > to get a zero key length: >=20 > flow create 1 pattern eth / end actions rss key "" / end >=20 > Because "" is interpreted literally. So the only way to request a zero ke= y > length is by explicitly setting it through "key_len 0". >=20 > The API remains clear: a zero key length requests default behavior from t= he > PMD regardless of the key pointer, which doesn't *have* to be NULL, merel= y > undefined. Testpmd does exactly that. IMO, it will make it more clear if the key will *have* to be null, because = there is no single good reason to have it otherwise.=20 However it looks like an endless debate between strict and relaxed API. the= re are points to both sides, yet we are failing to converge. Mlx5 already implements according to the rss_key_len and rss_key approach. = What are other PMD doing? Assuming there is a consensus among the PMDs, maybe we can follow it in ord= er to avoid the extra work. is it that critical for you to enforce only the key_len w/o the rss_key?=20 >=20 > > To this doc issue, > > I don't understand on what cases it makes sense for application to have > rss_key_len =3D 0 while rss_key !=3D NULL. This is obviously in-consist i= nput, 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 requirem= ent > from application, and it makes no confusion in the API inputs. >=20 > Then you need to define what happens when key_len !=3D 0 and key =3D=3D N= ULL, > also when key_len =3D=3D 0 and key !=3D NULL, none of which make sense > currently. Of course all are in-consist and the PMD is free to reject such rules. This= is not related though to how we define the default RSS right?=20 >=20 > 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 reaso= n to, > it's a programming error in the application if not the case. > assert() is more appropriate for such situations. >=20 > 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. >=20 > > > 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 inste= ad of 0. > > > > > > > > > > > > [1] "app/testpmd: revert setting default RSS" > > > > > > > https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fm > > > a > > > ils.dpdk.org%2Farchives%2Fdev%2F2018- > > > > November%2F118786.html&data=3D02%7C01%7Cshahafs%40mellanox.co > > > > m%7C0eecf3e9af4b4b6bc53108d6498ba2a8%7Ca652971c7d2e4d9ba6a4d1492 > > > > 56f461b%7C0%7C0%7C636777261425388073&sdata=3DHu0iGr2xS%2FI%2FI > > > s5PtzCylMMft5w5TBmtd3GYppEKKcA%3D&reserved=3D0 >=20 > -- > Adrien Mazarguil > 6WIND