From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 98EEE1B821 for ; Mon, 9 Apr 2018 19:02:24 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Apr 2018 10:02:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,427,1517904000"; d="scan'208";a="190051007" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by orsmga004.jf.intel.com with ESMTP; 09 Apr 2018 10:02:22 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.155]) by IRSMSX153.ger.corp.intel.com ([169.254.9.3]) with mapi id 14.03.0319.002; Mon, 9 Apr 2018 18:02:21 +0100 From: "Dumitrescu, Cristian" To: "Van Haaren, Harry" , Stephen Hemminger , "Singh, Jasvinder" , "Richardson, Bruce" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] table: fix build error with gcc 8 Thread-Index: AQHT0AFDvYx2RPzVvkK3GozvP95nyKP4eMUAgAAXc8CAAAFNgIAAEVwg Date: Mon, 9 Apr 2018 17:02:20 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891267BB3D42E@IRSMSX108.ger.corp.intel.com> References: <20180409124948.130974-1-jasvinder.singh@intel.com> <20180409080936.58ecb66c@xeon-e3> <3EB4FA525960D640B5BDFFD6A3D891267BB3D389@IRSMSX108.ger.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] table: fix build error with gcc 8 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: Mon, 09 Apr 2018 17:02:25 -0000 > -----Original Message----- > From: Van Haaren, Harry > Sent: Monday, April 9, 2018 5:38 PM > To: Dumitrescu, Cristian ; Stephen > Hemminger ; Singh, Jasvinder > ; Richardson, Bruce > > Cc: dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH] table: fix build error with gcc 8 >=20 > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Dumitrescu, > Cristian > > Sent: Monday, April 9, 2018 4:59 PM > > To: Stephen Hemminger ; Singh, > Jasvinder > > ; Richardson, Bruce > > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH] table: fix build error with gcc 8 > > > > > > > > > -----Original Message----- > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > > Sent: Monday, April 9, 2018 4:10 PM > > > To: Singh, Jasvinder > > > Cc: dev@dpdk.org; Dumitrescu, Cristian > > > Subject: Re: [dpdk-dev] [PATCH] table: fix build error with gcc 8 > > > > > > On Mon, 9 Apr 2018 13:49:48 +0100 > > > Jasvinder Singh wrote: > > > > > > > Fix build error with gcc 8.0 due to cast between function types. > > > > Fixes: 5a80bf0ae613 ("table: add cuckoo hash") > > > > > > > > Signed-off-by: Jasvinder Singh > > > > --- > > > > lib/librte_table/rte_table_hash_cuckoo.c | 4 +++- > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/lib/librte_table/rte_table_hash_cuckoo.c > > > b/lib/librte_table/rte_table_hash_cuckoo.c > > > > index dcb4fe9..f7eae27 100644 > > > > --- a/lib/librte_table/rte_table_hash_cuckoo.c > > > > +++ b/lib/librte_table/rte_table_hash_cuckoo.c > > > > @@ -103,11 +103,13 @@ rte_table_hash_cuckoo_create(void > *params, > > > > return NULL; > > > > } > > > > > > > > + void *hash_func =3D p->f_hash; > > > > + > > > > /* Create cuckoo hash table */ > > > > struct rte_hash_parameters hash_cuckoo_params =3D { > > > > .entries =3D p->n_keys, > > > > .key_len =3D p->key_size, > > > > - .hash_func =3D (rte_hash_function)(p->f_hash), > > > > + .hash_func =3D (rte_hash_function) hash_func, > > > > .hash_func_init_val =3D p->seed, > > > > .socket_id =3D socket_id, > > > > .name =3D p->name > > > > > > This is just tricking the compiler into not complaining. > > > I would really rather see the two hash functions made the same. > > > > (Adding Bruce as well to consolidate all conversations in a single thre= ad.) > > > > What we want to do here is be able to use the librte_hash under the sam= e > API > > as the several hash table flavors implemented in librte_table. > > > > Both of these libraries allow configuring the hash function per each ha= sh > > table instance. Problem is: hash function in librte_hash has only 3 > parameters > > (no key mask), while hash function in librte_table has 4 parameters > (includes > > key mask). The key mask helps a lot for practical protocol implementati= ons > by > > avoiding key copy & pre-process on lookup. > > > > So then: how to plug in librte_hash under the same API as the suite of > hash > > tables in librte_table? We don't want to re-implement cuckoo hash from > > librte_hash, we simply want to invoke it as a low-level primitive, simi= larly > > to how the LPM and ACL tables are plugged into librte_table. > > > > Solution is: as an exception, pass a 3-parameter hash function to cucko= o > hash > > flavor under the librte_table. Maybe this should be documented better. > This > > currently triggers a build warning with gcc 8, which is easy to fix, he= nce > > this trivial patch. > > > > Ideally, for every 3-parameter hash function, I would like to generate = the > > corresponding 4-parameter hash function on-the-fly, but unfortunately t= his > is > > not what C language can do. > > > > Of course, IMO the best solution is to add key mask support to librte_h= ash. >=20 >=20 > Looking at the previous discussion I see the following as a possible solu= tion; >=20 > Given the current code looks broken it should be fixed in this release. The code is not broken. This is not a bug, it is a limitation for that part= icular table type. The only gap that I see is adding a Doxygen comment in t= he API header file. User explicitly picks the hash table type it wants; when using this particu= lar hash table type, that pointer needs to point to a 3-parameter function = instead of 4. Given the limitation is clearly documented in Doxygen (curren= t gap that we can quickly address), I don't see any problem. If people think that this function conversion is not nice, it can be rework= ed in multiple ways at the expense of API (but not ABI) change: 1. Define the hash function field in the table parameter structure as opaqu= e void * rather than 4-parameter version. 2. Create a separate parameter structure just for this hash table type. > Given the actual code fix is an API / ABI break (depending on solution) i= t > cannot be merged official in this release. > We have a NEXT_ABI macro - it allows us to break API/ABI conditionally at > compile time. This is not new code introduced in this release cycle, this is just fixing = the compiler warning, I fail to see how your ABI breakage mention is applic= able. Maybe we should talk more specifics over the code, where exactly in the cod= e would you like to place your NEXT_ABI macro? >=20 > With the above 3 points, I think the best solution is to correctly fix th= e > problem that GCC 8 is identifying, and putting that new API inside the NE= XT_ > macros. >=20 > In this case, we can preserve backwards (buggy) behavior if required, and > provide correct (but API/ABI breaking) code as well. This is a tough deci= sion - > particularly for distros - what do they package? >=20 > Given the current code, I don't see a better solution - but I hope I'm wr= ong :)