From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0044.outbound.protection.outlook.com [104.47.1.44]) by dpdk.org (Postfix) with ESMTP id 233E1201 for ; Thu, 8 Nov 2018 09:50:15 +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=TdBoHI6CpFzDDnRzK/3LJYNbbI6kJG8I/IgPRO4RBpI=; b=cqcrZV2Uk51PeU/CrDU/SA27azGxBfuUfHgAa9V8fUQPWOiekWwhg6pbXgSl0Z1gEZtCj1bAjdrDwkyOUYMISuMxI0n0yYEvq//OQ5yiPLF6L4KE1WyK3fw19yOjOKCKk8avncNQLfwrOtnfbZNTkm6Rm0NATUdLe41u0wk4iQ4= Received: from VI1PR0502MB3743.eurprd05.prod.outlook.com (52.134.8.154) by VI1PR0502MB3726.eurprd05.prod.outlook.com (52.134.8.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.30; Thu, 8 Nov 2018 08:50:12 +0000 Received: from VI1PR0502MB3743.eurprd05.prod.outlook.com ([fe80::84d3:8812:d45c:98e4]) by VI1PR0502MB3743.eurprd05.prod.outlook.com ([fe80::84d3:8812:d45c:98e4%4]) with mapi id 15.20.1294.034; Thu, 8 Nov 2018 08:50:12 +0000 From: Ophir Munk To: Adrien Mazarguil CC: Ferruh Yigit , Andrew Rybchenko , "dev@dpdk.org" , Thomas Monjalon , Asaf Penso , Shahaf Shuler , Olga Shern Thread-Topic: [dpdk-dev] [PATCH v2] ethdev: document RSS default key and types Thread-Index: AQHUdnuTE9UKU0bjB02/QczzO0OvtKVEDEOAgAAxJTCAABurAIAADKLwgAAevoCAAQ4DkA== Date: Thu, 8 Nov 2018 08:50:12 +0000 Message-ID: References: <1541259953-4273-1-git-send-email-ophirmu@mellanox.com> <1541582611-1609-1-git-send-email-ophirmu@mellanox.com> <20181107093109.GG4638@6wind.com> <20181107140604.GL4638@6wind.com> <20181107164118.GM4638@6wind.com> In-Reply-To: <20181107164118.GM4638@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=ophirmu@mellanox.com; x-originating-ip: [109.186.53.234] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0502MB3726; 6:TgThxZbHH8JyLNWHBx4LT03mwklH9koAh/Y0q0GUO9/YqExZd5KuVb7dwzmljB/ZkZ2D+h++Q8KGW8q90pK/83jTsedFLtwNs8oFw5TGKQHUM91Vf7O2NqoA3aXMcEq2B3ITDsOurbz5EkjBLIHHuCOXynC5+WAndRW3y2XQt64ArI+IrXBZKP1yYzJTgQZeuTv92FlAOMZRjirE5C8Z4fbelP+2GL8S0C/rSh2P2sFdDtwykdU49amta4R4nEXUa7speQxIbsA7toer8jadxuAbtvNJz7yox3gsusbREiexdgDNCdrWG3iBcPtiYZNVaGyuOdFj32XU+qfP/SpuRb6nhjJQYpJ238MtmkQvZSsU/qUtSumiEY8b0VwHPaKeFeNmVst60y9vBgCegRvQr751p7Uth0H3dN9hP0bGNER6qJfmJieQYtFR5gaimRa5DkWqQH/A9ozC4WZd0stapQ==; 5:YWQS61SsXYCGdLw/AyBJs56jKDcG7LDNJmUEXcoQCPr/CmtkCf0EHrVPaEkJZul/nmoAgXdVoINacTND6rwCO4oKPVO/FV28OYQH7jZW+bg5JPs7OTallwdGRnHR1Yyte3ak/EhCy8yqg164LF85Ym70cjLHcZNuhG2lLT44mWU=; 7:rzRAa6G9KafnAVD1anGltGSZsClFINeup4rZCND55EFwNGZ+Yih3qfRvjGR2L45hDqKXn3eB5nJ7Lv7ZZXdYr/NSa9ADKUPPr+13dGYyHWUqlM7vzdak6bH34kCm3fwb+vTLMI9x5NoClM9cJN1Ncw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 779675f3-5e56-4552-cb3e-08d645573232 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0502MB3726; x-ms-traffictypediagnostic: VI1PR0502MB3726: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(45079756050767)(189930954265078)(278428928389397)(228905959029699); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231382)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201703061421075)(201703161042150)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6042181)(201708071742011)(7699051)(76991095); SRVR:VI1PR0502MB3726; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0502MB3726; x-forefront-prvs: 0850800A29 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(199004)(189003)(13464003)(105586002)(97736004)(498600001)(186003)(14454004)(6436002)(106356001)(256004)(55016002)(86362001)(575784001)(2900100001)(9686003)(74316002)(8936002)(107886003)(6246003)(45080400002)(6916009)(305945005)(4326008)(7736002)(6306002)(476003)(81166006)(66066001)(93886005)(26005)(25786009)(68736007)(3846002)(99286004)(71200400001)(71190400001)(446003)(7696005)(81156014)(229853002)(33656002)(53546011)(76176011)(53936002)(2906002)(966005)(54906003)(6116002)(102836004)(5660300001)(486006)(6506007)(11346002)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0502MB3726; H:VI1PR0502MB3743.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: 8w3nQTvDnSCw8VNPHnKiZFUdYSLEUhyIzhNF+x+bw5fjr7gT6qViPiC16sT1wXZBVi3E30M7nRuoc/5GL4mFna2bnDJ6MTPGhZBPWzOYwa7nKodC/SQ5mYyI0QP3DND3Gw6H502l68KVjJcg1tDazxH1EnJl9Zv+0DX7SL/cdzEM7EXQ7xNElWP2WgS12dysucYoXbX7JwX0wd85VYF1Wvv2wbDAWlxSQvPxd00XXoPubpNjkFIkeKqv+zgNnDJlMOIJU7XR8K3+5Lgay9SpYf/BA4SLurFEWKvc5ko9VfMj9dtXj0b/Kq+1hPCZ311HokZOV6R+Am91i7BLnY3ObbgZG/1R5oMSTYQY9VeN134= 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: 779675f3-5e56-4552-cb3e-08d645573232 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2018 08:50:12.5383 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0502MB3726 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: Thu, 08 Nov 2018 08:50:15 -0000 > -----Original Message----- > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > Sent: Wednesday, November 07, 2018 6:41 PM > To: Ophir Munk > Cc: Ferruh Yigit ; Andrew Rybchenko > ; dev@dpdk.org; Thomas Monjalon > ; Asaf Penso ; Shahaf > Shuler ; Olga Shern > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: document RSS default key and > types >=20 > On Wed, Nov 07, 2018 at 03:13:07PM +0000, Ophir Munk wrote: > > > > > -----Original Message----- > > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > > > Sent: Wednesday, November 07, 2018 4:06 PM > > > To: Ophir Munk > > > Cc: Ferruh Yigit ; Andrew Rybchenko > > > ; dev@dpdk.org; Thomas Monjalon > > > ; Asaf Penso ; Shahaf > > > Shuler ; Olga Shern > > > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: document RSS default key > > > and types > > > > > > On Wed, Nov 07, 2018 at 12:39:24PM +0000, Ophir Munk wrote: > > > > > -----Original Message----- > > > > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > > > > > Sent: Wednesday, November 07, 2018 11:31 AM > > > > > To: Ophir Munk > > > > > Cc: Ferruh Yigit ; Andrew Rybchenko > > > > > ; dev@dpdk.org; Thomas Monjalon > > > > > ; Asaf Penso ; > Shahaf > > > > > Shuler ; Olga Shern > > > > > > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: document RSS default > > > > > key and types > > > > > > > > > > On Wed, Nov 07, 2018 at 09:23:42AM +0000, Ophir Munk wrote: > > > > > > struct rte_flow_action_rss include fields 'key' and 'types'. > > > > > > Field 'key' is a pointer to bytes array (uint8_t *) which > > > > > > contains the specific RSS hash key. > > > > > > If an application is only interested in default RSS operation > > > > > > it should not care about the specific hash key. The > > > > > > application can set the hash key to NULL such that any PMD uses= its > default RSS key. > > > > > > > > > > > > Field 'types' is a uint64_t bits flag used to specify a > > > > > > specific RSS hash type such as ETH_RSS_IP (see ETH_RSS_*). > > > > > > If an application does not care about the specific RSS type it > > > > > > can set this field to 0 such that any PMD uses its default type= . > > > > > > > > > > > > Signed-off-by: Ophir Munk > > > > > > --- > > > > > > lib/librte_ethdev/rte_flow.h | 9 +++++++-- > > > > > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > > > > > > > > > diff --git a/lib/librte_ethdev/rte_flow.h > > > > > > b/lib/librte_ethdev/rte_flow.h index c0fe879..ca9e135 100644 > > > > > > --- a/lib/librte_ethdev/rte_flow.h > > > > > > +++ b/lib/librte_ethdev/rte_flow.h > > > > > > @@ -1782,10 +1782,15 @@ struct rte_flow_action_rss { > > > > > > * through. > > > > > > */ > > > > > > uint32_t level; > > > > > > - uint64_t types; /**< Specific RSS hash types (see > ETH_RSS_*). */ > > > > > > + /** > > > > > > + * Specific RSS hash types (see ETH_RSS_*), > > > > > > + * or 0 for PMD specific default. > > > > > > + */ > > > > > > + uint64_t types; > > > > > > uint32_t key_len; /**< Hash key length in bytes. */ > > > > > > uint32_t queue_num; /**< Number of entries in @p queue. > */ > > > > > > - const uint8_t *key; /**< Hash key. */ > > > > > > + /** Hash key, or NULL for PMD specific default key. */ > > > > > > + const uint8_t *key; > > > > > > > > > > I'd suggest to document that on key_len instead. If key_len is > > > > > nonzero, key cannot be NULL anyway. > > > > > > > > The decision if a key/len combination is valid is done in the PMD > > > > action > > > validation API. > > > > For example, in MLX5 key=3D=3DNULL and key_len=3D=3D40 is accepted. > > > > The combination key=3D=3DNULL and key_len=3D=3D0 should always succ= eeds, > > > however the "must" parameter for RSS default is key=3D=3DNULL and not > > > key_len=3D=3D0. > > > > > > I understand this is how the mlx5 PMD implemented it, but my point > > > is that it makes more sense API-wise to define key_len =3D=3D 0 as th= e > > > trigger for a default RSS hash key than key =3D=3D NULL. > > > > > > My suggestion is to follow the same trend as memcpy(), mmap(), > > > snprintf() and other well-known functions that take a size when > > > dealing with NULL/undefined pointers. Only size matters! :) > > > > > > > Please let's stay backward compatible and consistent with previous > > dpdk releases where key=3D=3DNULL is used in struct rte_eth_rss_conf (s= ee > code snippet in [1]). >=20 > And I thought I wouldn't hear again from that structure after ac8d22de239= 4 > ("ethdev: flatten RSS configuration in flow API") got rid of it in rte_fl= ow > :) >=20 > There is no need to be backward compatible with it particularly if doing = so > improves consistency (assuming you agree it does). >=20 > Take "rss_hf" versus "types" fields for instance [2]. Unsetting the forme= r > disables RSS completely while unsetting the latter provides default RSS > settings for that flow rule, simply because a RSS action that doesn't do = RSS > makes no sense (one could provide a single queue for that). >=20 > Regarding "key_len", have a look at this other message [3] in the same > thread which clearly states that i40e expects a zero key length to trigge= r > default RSS, it doesn't rely on a NULL pointer. >=20 > Generally speaking, I'm pushing for zero values in action objects to resu= lt in a > safe default behavior. A nonzero key_len with a NULL key may result in a > crash, while the reverse is inherently safer since one doesn't even need = to > check the size or pointer validity, e.g.: >=20 > memcpy(target_device_rss_stuff, rss_conf->key, rss_conf->key_len); >=20 > What's not to like? >=20 Some think key=3D=3DNULL && key_len!=3D0 is senseless while other think key= !=3DNULL && key_len=3D=3D0 is senseless. Let's agree on both key=3D=3DNULL && key_len=3D=3D0. > [2] "Re: [PATCH v2 07/15] ethdev: flatten RSS configuration in flow API" >=20 > https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmai > ls.dpdk.org%2Farchives%2Fdev%2F2018- > April%2F096235.html&data=3D02%7C01%7Cophirmu%40mellanox.com% > 7C4fdd2e5a838047c152c408d644cfe439%7Ca652971c7d2e4d9ba6a4d14925 > 6f461b%7C0%7C0%7C636772057013784575&sdata=3D6JsomMO68lJoiNd > ehRaNdn2xG9BSAgqCjxwpJJJOP8A%3D&reserved=3D0 >=20 > [3] "Re: [dpdk-dev] [PATCH v6 07/16] ethdev: flatten RSS configuration in > flow API" >=20 > https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmai > ls.dpdk.org%2Farchives%2Fdev%2F2018- > May%2F100128.html&data=3D02%7C01%7Cophirmu%40mellanox.com%7 > C4fdd2e5a838047c152c408d644cfe439%7Ca652971c7d2e4d9ba6a4d149256 > f461b%7C0%7C0%7C636772057013784575&sdata=3DTXDTKLho8qyKlH%2 > FqBturGHWhvdfaACuMoqvl0eOjfcU%3D&reserved=3D0 >=20 > > We should avoid confusing applications with setting key=3D=3DNULL with > legacy RSS and key_len=3D=3D0 with rte_flows. > > > > With regard to trends APIs - I was thinking about free() where a NULL > > pointer is acceptable :) >=20 > Yeah, though free() doesn't take a size. On the other hand the behavior o= f > realloc() is much more interesting when faced with a zero size :) That's > probably one of the few exceptions so I guess my point still stands. >=20 > > > > [1] > > File lib/librte_ethdev/rte_ethdev.h: > > > > /** > > * A structure used to configure the Receive Side Scaling (RSS) > > feature > > * of an Ethernet port. > > * If not NULL, the *rss_key* pointer of the *rss_conf* structure > > points > > * to an array holding the RSS key to use for hashing specific header > > * fields of received packets. The length of this array should be > > indicated > > * by *rss_key_len* below. Otherwise, a default random hash key is > > used by > > * the device driver. > > * > > * The *rss_key_len* field of the *rss_conf* structure indicates the > > length > > * in bytes of the array pointed by *rss_key*. To be compatible, this > > length > > * will be checked in i40e only. Others assume 40 bytes to be used as > before. > > * > > * .......... > > */ > > struct rte_eth_rss_conf { > > uint8_t *rss_key; /**< If not NULL, 40-byte hash key. */ > > uint8_t rss_key_len; /**< hash key length in bytes. */ > > uint64_t rss_hf; /**< Hash functions to apply - see below. */ > > }; >=20 > -- > Adrien Mazarguil > 6WIND