From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 75B5C1B81A for ; Mon, 9 Apr 2018 17:58:43 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Apr 2018 08:58:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,427,1517904000"; d="scan'208";a="215201628" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga005.jf.intel.com with ESMTP; 09 Apr 2018 08:58:40 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.155]) by IRSMSX104.ger.corp.intel.com ([169.254.5.171]) with mapi id 14.03.0319.002; Mon, 9 Apr 2018 16:58:39 +0100 From: "Dumitrescu, Cristian" To: Stephen Hemminger , "Singh, Jasvinder" , "Richardson, Bruce" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] table: fix build error with gcc 8 Thread-Index: AQHT0AFDvYx2RPzVvkK3GozvP95nyKP4eMUAgAAXc8A= Date: Mon, 9 Apr 2018 15:58:39 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891267BB3D389@IRSMSX108.ger.corp.intel.com> References: <20180409124948.130974-1-jasvinder.singh@intel.com> <20180409080936.58ecb66c@xeon-e3> In-Reply-To: <20180409080936.58ecb66c@xeon-e3> 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 15:58:44 -0000 > -----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 >=20 > On Mon, 9 Apr 2018 13:49:48 +0100 > Jasvinder Singh wrote: >=20 > > 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 >=20 > 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 thread.) What we want to do here is be able to use the librte_hash under the same AP= I as the several hash table flavors implemented in librte_table. Both of these libraries allow configuring the hash function per each hash t= able instance. Problem is: hash function in librte_hash has only 3 paramete= rs (no key mask), while hash function in librte_table has 4 parameters (inc= ludes 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 of hash= tables in librte_table? We don't want to re-implement cuckoo hash from lib= rte_hash, we simply want to invoke it as a low-level primitive, similarly t= o how the LPM and ACL tables are plugged into librte_table. Solution is: as an exception, pass a 3-parameter hash function to cuckoo ha= sh flavor under the librte_table. Maybe this should be documented better. T= his 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 this = is not what C language can do. Of course, IMO the best solution is to add key mask support to librte_hash. Regards, Cristian