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 D5D001B843 for ; Mon, 9 Apr 2018 18:38:14 +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 09:38:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,427,1517904000"; d="scan'208";a="31993392" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by orsmga007.jf.intel.com with ESMTP; 09 Apr 2018 09:38:13 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.176]) by IRSMSX154.ger.corp.intel.com ([169.254.12.234]) with mapi id 14.03.0319.002; Mon, 9 Apr 2018 17:38:12 +0100 From: "Van Haaren, Harry" To: "Dumitrescu, Cristian" , Stephen Hemminger , "Singh, Jasvinder" , "Richardson, Bruce" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] table: fix build error with gcc 8 Thread-Index: AQHT0AFSoFIUIDcUxUmbURS24rQGhKP4eMUAgAANtICAABoPMA== Date: Mon, 9 Apr 2018 16:38:11 +0000 Message-ID: References: <20180409124948.130974-1-jasvinder.singh@intel.com> <20180409080936.58ecb66c@xeon-e3> <3EB4FA525960D640B5BDFFD6A3D891267BB3D389@IRSMSX108.ger.corp.intel.com> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891267BB3D389@IRSMSX108.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNjRhYTA0NGItNWU2Yi00ODJlLTgwMWItZjM1MTY4NTE4M2M0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjIuNS4xOCIsIlRydXN0ZWRMYWJlbEhhc2giOiIzK3lvWkxjT3JGd3BPbXJhOVJrZHVKNmJYZUhKMU9aNjAxblZycVdxRVZLNlQ3YjBYS1NOWHFMNDBPNnFvUXphIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [163.33.239.181] 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 16:38:15 -0000 > 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 >=20 >=20 >=20 > > -----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. >=20 > (Adding Bruce as well to consolidate all conversations in a single thread= .) >=20 > What we want to do here is be able to use the librte_hash under the same = API > as the several hash table flavors implemented in librte_table. >=20 > Both of these libraries allow configuring the hash function per each hash > table instance. Problem is: hash function in librte_hash has only 3 param= eters > (no key mask), while hash function in librte_table has 4 parameters (incl= udes > key mask). The key mask helps a lot for practical protocol implementation= s by > avoiding key copy & pre-process on lookup. >=20 > So then: how to plug in librte_hash under the same API as the suite of ha= sh > 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, simila= rly > to how the LPM and ACL tables are plugged into librte_table. >=20 > Solution is: as an exception, pass a 3-parameter hash function to cuckoo = hash > flavor under the librte_table. Maybe this should be documented better. Th= is > currently triggers a build warning with gcc 8, which is easy to fix, henc= e > this trivial patch. >=20 > Ideally, for every 3-parameter hash function, I would like to generate th= e > corresponding 4-parameter hash function on-the-fly, but unfortunately thi= s is > not what C language can do. >=20 > Of course, IMO the best solution is to add key mask support to librte_has= h. Looking at the previous discussion I see the following as a possible soluti= on; Given the current code looks broken it should be fixed in this release. 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 c= ompile time. 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, and p= rovide correct (but API/ABI breaking) code as well. This is a tough decisio= n - particularly for distros - what do they package? Given the current code, I don't see a better solution - but I hope I'm wron= g :)