From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id D74DD1B7EA for ; Mon, 9 Apr 2018 19:09:49 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Apr 2018 10:09:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,427,1517904000"; d="scan'208";a="32000750" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by orsmga007.jf.intel.com with ESMTP; 09 Apr 2018 10:09:46 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.164]) by IRSMSX151.ger.corp.intel.com ([169.254.4.181]) with mapi id 14.03.0319.002; Mon, 9 Apr 2018 18:09:46 +0100 From: "Ananyev, Konstantin" To: "Dumitrescu, Cristian" , "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: AQHT0AFSOz5R08ou8kySHxHKDu2+xKP4eMUAgAANtICAAAsMgIAABr8AgAARi6A= Date: Mon, 9 Apr 2018 17:09:44 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258AE912640@IRSMSX102.ger.corp.intel.com> References: <20180409124948.130974-1-jasvinder.singh@intel.com> <20180409080936.58ecb66c@xeon-e3> <3EB4FA525960D640B5BDFFD6A3D891267BB3D389@IRSMSX108.ger.corp.intel.com> <3EB4FA525960D640B5BDFFD6A3D891267BB3D42E@IRSMSX108.ger.corp.intel.com> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891267BB3D42E@IRSMSX108.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZWEzOTIwNjYtMDdiZi00ZmJjLWIzNzktZTRjOTA2NjY0MGM0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IjZrT2dQSW5VTUFsZUg4TVJkOVFNZ3dJM25hd3Y5MWNPWmhJYktVT1NCYkU9In0= x-ctpclassification: CTP_NT 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:09:50 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Dumitrescu, Cristian > Sent: Monday, April 9, 2018 6:02 PM > To: Van Haaren, Harry ; Stephen Hemminger ; Singh, Jasvinder > ; Richardson, Bruce > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] table: fix build error with gcc 8 >=20 >=20 >=20 > > -----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 > > > > > 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 th= read.) > > > > > > What we want to do here is be able to use the librte_hash under the s= ame > > API > > > as the several hash table flavors implemented in librte_table. > > > > > > Both of these libraries allow configuring the hash function per each = hash > > > 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 implementa= tions > > by > > > avoiding key copy & pre-process on lookup. > > > > > > So then: how to plug in librte_hash under the same API as the suite o= f > > hash > > > tables in librte_table? We don't want to re-implement cuckoo hash fro= m > > > librte_hash, we simply want to invoke it as a low-level primitive, si= milarly > > > to how the LPM and ACL tables are plugged into librte_table. > > > > > > Solution is: as an exception, pass a 3-parameter hash function to cuc= koo > > 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, = hence > > > this trivial patch. > > > > > > Ideally, for every 3-parameter hash function, I would like to generat= e the > > > corresponding 4-parameter hash function on-the-fly, but unfortunately= this > > is > > > not what C language can do. > > > > > > Of course, IMO the best solution is to add key mask support to librte= _hash. > > > > > > Looking at the previous discussion I see the following as a possible so= lution; > > > > Given the current code looks broken it should be fixed in this release. >=20 > The code is not broken. This is not a bug, it is a limitation for that pa= rticular table type. The only gap that I see is adding a Doxygen > comment in the API header file. >=20 > User explicitly picks the hash table type it wants; when using this parti= cular hash table type, that pointer needs to point to a 3-parameter > function instead of 4. Given the limitation is clearly documented in Doxy= gen (current gap that we can quickly address), I don't see any > problem. >=20 > If people think that this function conversion is not nice, it can be rewo= rked in multiple ways at the expense of API (but not ABI) change: > 1. Define the hash function field in the table parameter structure as opa= que void * rather than 4-parameter version. > 2. Create a separate parameter structure just for this hash table type. Why just not define your f_hash member as a union: struct rte_table_hash_params { ... union { rte_table_hash_op_hash f_hash_4params; rte_hash_function f_hash_3_params; };=20 ? >=20 > > Given the actual code fix is an API / ABI break (depending on solution)= it > > cannot be merged official in this release. > > We have a NEXT_ABI macro - it allows us to break API/ABI conditionally = at > > compile time. >=20 > This is not new code introduced in this release cycle, this is just fixin= g the compiler warning, I fail to see how your ABI breakage mention is > applicable. >=20 > Maybe we should talk more specifics over the code, where exactly in the c= ode would you like to place your NEXT_ABI macro? >=20 > > > > With the above 3 points, I think the best solution is to correctly fix = the > > problem that GCC 8 is identifying, and putting that new API inside the = NEXT_ > > macros. > > > > In this case, we can preserve backwards (buggy) behavior if required, a= nd > > provide correct (but API/ABI breaking) code as well. This is a tough de= cision - > > particularly for distros - what do they package? > > > > Given the current code, I don't see a better solution - but I hope I'm = wrong :)