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 1E18D8E83 for ; Tue, 13 Oct 2015 13:44:28 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP; 13 Oct 2015 04:44:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,677,1437462000"; d="scan'208";a="579729933" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by FMSMGA003.fm.intel.com with ESMTP; 13 Oct 2015 04:44:28 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.138]) by irsmsx105.ger.corp.intel.com ([169.254.7.75]) with mapi id 14.03.0248.002; Tue, 13 Oct 2015 12:44:26 +0100 From: "Dumitrescu, Cristian" To: "Yeddula, Avinash" , "dev@dpdk.org" , "Bly, Mike" Thread-Topic: DPDK hash function related question Thread-Index: AdD0vV0EWrwqSA3rT+Ksi8qmzYCTywAYFeSgA/xM2ZAAJ2P1cA== Date: Tue, 13 Oct 2015 11:44:25 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D89126478EE91E@IRSMSX108.ger.corp.intel.com> References: <3EB4FA525960D640B5BDFFD6A3D89126478D64A1@IRSMSX108.ger.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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] DPDK hash function related question X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 11:44:29 -0000 > -----Original Message----- > From: Yeddula, Avinash [mailto:ayeddula@ciena.com] > Sent: Monday, October 12, 2015 6:03 PM > To: Dumitrescu, Cristian; dev@dpdk.org; Bly, Mike > Subject: RE: DPDK hash function related question >=20 > Hi Cristian, > I have configured the hash function and it compile fine with "warnings". = Since > librte_hash vs librte_table is 32bit vs 64bit. >=20 > librte_hash library : > /** Type of function that can be used for calculating the hash value. */ > typedef uint32_t (*rte_hash_function)(const void *key, uint32_t key_len, > uint32_t init_val); >=20 > librte_table library: > typedef uint64_t (*rte_table_hash_op_hash) (void *key, uint32_t > key_size, uint64_t seed); >=20 > I could use one of these hash functions. This is one option, but our firs= t > priority is to use crc hash or cukoo hash. > https://github.com/scylladb/dpdk/blob/master/examples/ip_pipeline/pipeli > ne/hash_func.h >=20 > We do not want to have those warning in our code. What do you suggest ? Would function pointer conversion work? >=20 > Thanks > -Avinash >=20 > -----Original Message----- > From: Dumitrescu, Cristian [mailto:cristian.dumitrescu@intel.com] > Sent: Tuesday, September 22, 2015 3:05 AM > To: Yeddula, Avinash; dev@dpdk.org; Bly, Mike > Subject: RE: DPDK hash function related question >=20 > Hi Avinash, >=20 > Yes, the hash function is configurable. >=20 > Are you using a DPDK release older than 2.1? In DPDK we moved away from > test_hash to CRC-based hashes. Please take a look at DPDK release 2.1 > examples/ip_pipeline application: in pipeline_flow_classification_be.c, w= e > use CRC-based hash functions defined in file hash_func.h from the same > folder. >=20 > Regards, > Cristian >=20 > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yeddula, Avinash > > Sent: Tuesday, September 22, 2015 1:34 AM > > To: dev@dpdk.org; Bly, Mike > > Subject: [dpdk-dev] DPDK hash function related question > > > > Hello All, > > > > I'm DPDK extensible bucket hash in the rte_table library of packet > > framework. My question is related to the actual hash function that > > computes the hash signature. > > > > All the available examples have initialized it to test_hash. I do not= see any > > hash function available in rte_table library , that computes the > > actual signature > > > > > > > > struct rte_table_hash_ext_params hash_table_params =3D { > > > > .key_size =3D TABLE_ENTRY_KEY_SIZE, > > > > .n_keys =3D TABLE_MAX_SIZE, > > > > .n_buckets =3D TABLE_MAX_BUCKET_COUNT, > > > > .n_buckets_ext =3D TABLE_MAX_EXT_BUCKET_COUNT, > > > > .f_hash =3D test_hash, > > > > .seed =3D 0, > > > > .signature_offset =3D 0; > > > > .key_offset =3D __builtin_offsetof(struct metadata_t, tbl_key), > > > > }; > > > > > > > > So, I wanted to use hash functions from DPDK rte_hash library. This is > > what I'm doing and looking at the code this looks ok to me. > > > > I'm at least a week or 2 away from testing this part of the code. I > > wanted to confirm that, there is no fundamental flaw in using the DPDK > > rte_hash library and rte_table library like this. Could someone confirm= this > please ? > > > > > > > > #define DEFAULT_HASH_FUNC rte_hash_crc > > > > > > > > struct rte_table_hash_ext_params hash_table_params =3D { > > > > .key_size =3D TABLE_ENTRY_KEY_SIZE, > > > > .n_keys =3D TABLE_MAX_SIZE, > > > > .n_buckets =3D TABLE_MAX_BUCKET_COUNT, > > > > .n_buckets_ext =3D TABLE_MAX_EXT_BUCKET_COUNT, > > > > .f_hash =3D DEFAULT_HASH_FUNC , > > > > .seed =3D 0, > > > > .signature_offset =3D 0; > > > > .key_offset =3D __builtin_offsetof(struct metadata_t, tbl_key), > > > > }; > > > > > > > > Thanks > > > > -Avinash > > >=20