From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40053.outbound.protection.outlook.com [40.107.4.53]) by dpdk.org (Postfix) with ESMTP id 5D02E9E4 for ; Sun, 11 Nov 2018 10:35:27 +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=mrbHy5f9j8yJzsCXqvseEuMVvm8MmWYb7h+GsUOvISk=; b=eEiIUA2aNeZxTS/KJrUxLY5Dwr7kUNwGEbq85uoNe/F47HS5YUJ3CU/+RUj9cVClRRd4SXeNDn1tV4OiLst4JP1qIjQP6h9chLAjfcIaLUD441+z84NhnBwpNKGZts6oDtTpIjmRGOjToqIp19sbugY1ua8wUlJ4C+5zoAlvrzA= Received: from AM4PR05MB3425.eurprd05.prod.outlook.com (10.171.187.142) by AM4PR05MB3300.eurprd05.prod.outlook.com (10.171.186.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.21; Sun, 11 Nov 2018 09:35:23 +0000 Received: from AM4PR05MB3425.eurprd05.prod.outlook.com ([fe80::61ec:ffec:5ebf:7bd6]) by AM4PR05MB3425.eurprd05.prod.outlook.com ([fe80::61ec:ffec:5ebf:7bd6%3]) with mapi id 15.20.1294.044; Sun, 11 Nov 2018 09:35:23 +0000 From: Ori Kam To: Ophir Munk , Yongseok Koh , Adrien Mazarguil , Andrew Rybchenko CC: Ferruh Yigit , "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: AQHUdnuZjrGnKTVK7EC5gVq89IZWd6VEDEOAgAA0mQCAABg3AIAAEryAgAAYpICAAQ60AIAA73+AgACYpgCAAzkjcA== Date: Sun, 11 Nov 2018 09:35:22 +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: 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=orika@mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR05MB3300; 6:xzKGPVyZjg60xKN7/P2XCCp2aeKQmAy1yWLDNsthhkN7IMNL35T26vg1kj2GjjMDcX7+5kCG6BV5mmGRog3zSXUX1bc9/ZKpjVHa79SayxOgwhN85yyEfOr/LIsbeoDqdPM5mNXxzHADXK1a5klZklaed0K86Qnq+0wYkh/9FZkCT+bDYVd0QqvnHVNwLtCZ5pS5LmfK/wqtYMSOgEIesbdcM4SPDaBwQkEPSNHkySdha277Mh5SGRLpdKU8uFaPQWq8lZvdXQXa77plWIwFvDaln/6QoYGKcYog26K3w/RvpyVQWnHrQdqGEAJR5XCg3GMoX7CeVCx1guTUs8jYEbWOMsyFArOWPg0+/s+ViyGAUxioOj72NGdG2ap1ytW1TLhWR4+kD5f4G3UkXYNEFEHG+dCyYSFNE5x/wVAsblxEtnx6X2p5LGQ1Gn5OY628y/qgYiQloCR0pCywsAHLmA==; 5:omrTWlNMpSHIyL1r2uRyDyPT2NIceUa2pLVHjFFS8nIl9zP00q28M+3WD4acPHOBzlwRm4NDqLMsVeExcRVlwsFyNeUSlGRP21A8x9FDI4ThclbML9fCHioR0tVQsr99faGns/DO+9QHP5N+TGsTYjltzZzS/bv42K7A6dDgGD4=; 7:gOAXwV+zOkTrbfsNCtFGDUMythfMmXzNUuV12oRhuoKtTXYYwIQnYVNcCqYU5WnIjd1ggHiIbm/5D0B2G7cLQpr6ZFO3w05Kp3nZRJFtRUfPR0bNpRiDxQlByxO8o0npYdXpP+m0Sa1NDbeKw3CRZQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 848735a9-aabb-40f3-27f8-08d647b900f6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390040)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM4PR05MB3300; x-ms-traffictypediagnostic: AM4PR05MB3300: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(45079756050767)(189930954265078)(228905959029699); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231402)(944501410)(52105112)(93006095)(93001095)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:AM4PR05MB3300; BCL:0; PCL:0; RULEID:; SRVR:AM4PR05MB3300; x-forefront-prvs: 08534B37A7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(136003)(366004)(39860400002)(13464003)(199004)(189003)(107886003)(55016002)(45080400002)(53936002)(93886005)(478600001)(6306002)(9686003)(229853002)(6246003)(6436002)(7736002)(33656002)(305945005)(66066001)(3846002)(4326008)(6116002)(2906002)(25786009)(74316002)(105586002)(106356001)(6506007)(53546011)(76176011)(8676002)(26005)(14444005)(2900100001)(68736007)(256004)(102836004)(81156014)(8936002)(81166006)(99286004)(14454004)(966005)(7696005)(575784001)(316002)(86362001)(446003)(486006)(54906003)(476003)(110136005)(5660300001)(11346002)(4744004)(97736004)(71190400001)(71200400001)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR05MB3300; H:AM4PR05MB3425.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: hk/C8GJDqqvxTJsYqKERsEfyN6Q2mlW99CJ53aQdRaWyb6V8fypuTilw72dt+xSYGYA6hpc7pjUy+L1Mz1B26KXvJ8aJfZ5AfpqvHKnUUG2RNmUuBxwM8pJsozUhWuLquHAmJsE1EcjhE/2HGF+qOlx63Q7ZMEp3cA3BcdNjswermc1pIzMILGEwTof8CmYtFIKNBVvQ2vUKph53z8KyTWCpkgOBwHGon4L39YLN3Kx3P/EPy9arLchzBZupSw1ykFRUVzSNwAk00yPElthlRBEECAHYaAdkcQ/pw9kVvA74jENOFCv/8V3r2d64hGEWBIIfebgqCKDZYdePCP7f7tZ/UzFW9ZTkAcTqkJZ0PM8= 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: 848735a9-aabb-40f3-27f8-08d647b900f6 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2018 09:35:22.9287 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR05MB3300 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: Sun, 11 Nov 2018 09:35:27 -0000 > -----Original Message----- > From: dev On Behalf Of Ophir Munk > Sent: Friday, November 9, 2018 10:14 AM > To: Yongseok Koh ; Adrien Mazarguil > ; Andrew Rybchenko > > Cc: Ferruh Yigit ; dev@dpdk.org; Thomas Monjalon > ; Asaf Penso ; Shahaf Shuler > ; Olga Shern > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: document RSS default key and t= ypes >=20 >=20 >=20 > > -----Original Message----- > > From: Yongseok Koh > > Sent: Friday, November 09, 2018 1:07 AM > > To: Ophir Munk ; Adrien Mazarguil > > ; Andrew Rybchenko > > > > Cc: Ferruh Yigit ; dev@dpdk.org; Thomas Monjalo= n > > ; Asaf Penso ; Shahaf > > Shuler ; Olga Shern > > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: document RSS default key and > > types > > > > > > > On Nov 8, 2018, at 12:50 AM, Ophir Munk > > wrote: > > > > > > > > > > > >> -----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 > > >> > > >> 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 ke= y > > >>>> 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 i= t > > >>>>>>> should not care about the specific hash key. The application ca= n > > >>>>>>> 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 specifi= c > > >>>>>>> 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 accepte= d. > > >>>>> The combination key=3D=3DNULL and key_len=3D=3D0 should always su= cceeds, > > >>>> 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= the > > >>>> 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_con= f > > >>> (see > > >> code snippet in [1]). > > >> > > >> And I thought I wouldn't hear again from that structure after > > >> ac8d22de2394 > > >> ("ethdev: flatten RSS configuration in flow API") got rid of it in > > >> rte_flow > > >> :) > > >> > > >> There is no need to be backward compatible with it particularly if > > >> doing so improves consistency (assuming you agree it does). > > >> > > >> Take "rss_hf" versus "types" fields for instance [2]. Unsetting the > > >> former 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). > > >> > > >> 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 trigger default RSS, it doesn't rely on a NULL pointer. > > >> > > >> Generally speaking, I'm pushing for zero values in action objects to > > >> result 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.: > > >> > > >> memcpy(target_device_rss_stuff, rss_conf->key, rss_conf->key_len); > > >> > > >> What's not to like? > > >> > > > > > > Some think key=3D=3DNULL && key_len!=3D0 is senseless while other thi= nk > > key!=3DNULL && key_len=3D=3D0 is senseless. > > > Let's agree on both key=3D=3DNULL && key_len=3D=3D0. > > > > A bug's already been found by our QA team. The following command > > crashes. > > flow create 0 ingress pattern eth / ipv6 / udp / end actions rss queu= es 0 end > > level 2 types udp end key_len 40 / end > > > > due to null pointer access in the following code: > > > > lib/librte_ethdev/rte_flow.c > > @@ -464,7 +464,7 @@ rte_flow_conv_action_conf(void *buf, const size_t > > size, > > }), > > size > sizeof(*dst.rss) ? sizeof(*dst.rss) := size); > > off =3D sizeof(*dst.rss); > > if (src.rss->key_len) { > > off =3D RTE_ALIGN_CEIL(off, sizeof(*dst.rss->ke= y)); > > tmp =3D sizeof(*src.rss->key) * src.rss->key_le= n; > > if (size >=3D off + tmp) > > dst.rss->key =3D rte_memcpy > > ((void *)((uintptr_t)dst.rss + = off), > > src.rss->key, tmp); > > off +=3D tmp; > > } > > > > > > I wanted to submit a patch to add a sanity check, > > > > - if (src.rss->key_len) { > > + if (src.rss->key && src.rss->key_len) { > > > > but looks like we should conclude this thread first? > > Or, does the fix make any sense regardless of having key_len=3D0 or key= =3Dnull > > for default key? > > Having more sanity check is no harm usually... > > > > > > Thanks, > > Yongseok > > >=20 > The setfault is the result of commit a4391f8bae ("app/testpmd: set defaul= t 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 applicatio= ns > limitation. >=20 > We should decide how an application can set default RSS without knowing > anything about keys. >=20 I agree with Adrian that the main criteria should be the length. Maybe the set default RSS in testpmd should get new parameter. > > > > > > > >> [2] "Re: [PATCH v2 07/15] ethdev: flatten RSS configuration in flow = API" > > >> > > >> > > https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fma > > >> i > > >> 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 > > >> > > >> [3] "Re: [dpdk-dev] [PATCH v6 07/16] ethdev: flatten RSS configurati= on in > > >> flow API" > > >> > > >> > > https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fma > > >> i > > >> 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 > > >> > > >>> We should avoid confusing applications with setting key=3D=3DNULL w= ith > > >> 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 :) > > >> > > >> Yeah, though free() doesn't take a size. On the other hand the > > >> behavior of > > >> 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. > > >> > > >>> > > >>> [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 heade= r > > >>> * 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, thi= s > > >>> length > > >>> * will be checked in i40e only. Others assume 40 bytes to be used a= s > > >> 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. */ > > >>> }; > > >> > > >> -- > > >> Adrien Mazarguil > > >> 6WIND Best, Ori