From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <cristian.dumitrescu@intel.com>
Received: from mga18.intel.com (mga18.intel.com [134.134.136.126])
 by dpdk.org (Postfix) with ESMTP id 826411B7D6
 for <dev@dpdk.org>; Mon,  9 Apr 2018 19:27:00 +0200 (CEST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
 by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 09 Apr 2018 10:26:59 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.48,427,1517904000"; d="scan'208";a="45469486"
Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66])
 by fmsmga001.fm.intel.com with ESMTP; 09 Apr 2018 10:26:58 -0700
Received: from irsmsx108.ger.corp.intel.com ([169.254.11.155]) by
 IRSMSX152.ger.corp.intel.com ([169.254.6.253]) with mapi id 14.03.0319.002;
 Mon, 9 Apr 2018 18:26:57 +0100
From: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, "Van Haaren, Harry"
 <harry.van.haaren@intel.com>,
 Stephen Hemminger <stephen@networkplumber.org>, 
 "Singh, Jasvinder" <jasvinder.singh@intel.com>, "Richardson, Bruce"
 <bruce.richardson@intel.com>
CC: "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [dpdk-dev] [PATCH] table: fix build error with gcc 8
Thread-Index: AQHT0AFDvYx2RPzVvkK3GozvP95nyKP4eMUAgAAXc8CAAAFNgIAAEVwg///3dQCAABUvMA==
Date: Mon, 9 Apr 2018 17:26:57 +0000
Message-ID: <3EB4FA525960D640B5BDFFD6A3D891267BB3D47F@IRSMSX108.ger.corp.intel.com>
References: <20180409124948.130974-1-jasvinder.singh@intel.com>
 <20180409080936.58ecb66c@xeon-e3>
 <3EB4FA525960D640B5BDFFD6A3D891267BB3D389@IRSMSX108.ger.corp.intel.com>
 <E923DB57A917B54B9182A2E928D00FA65E020A2F@IRSMSX101.ger.corp.intel.com>
 <3EB4FA525960D640B5BDFFD6A3D891267BB3D42E@IRSMSX108.ger.corp.intel.com>
 <2601191342CEEE43887BDE71AB977258AE912640@IRSMSX102.ger.corp.intel.com>
In-Reply-To: <2601191342CEEE43887BDE71AB977258AE912640@IRSMSX102.ger.corp.intel.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Apr 2018 17:27:00 -0000

> >
> > If people think that this function conversion is not nice, it can be re=
worked
> in multiple ways at the expense of API (but not ABI) change:
> > 1. Define the hash function field in the table parameter structure as
> opaque void * rather than 4-parameter version.
> > 2. Create a separate parameter structure just for this hash table type.
>=20
> Why just not define your f_hash member as a union:
>=20
> struct rte_table_hash_params {
> ...
> union {
>     rte_table_hash_op_hash  f_hash_4params;
>     rte_hash_function f_hash_3_params;
> };
>=20
> ?
>=20

Yes, agreed, this is yet another way to handle this, thanks Konstantin.