From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by dpdk.org (Postfix) with ESMTP id 208688E78 for ; Mon, 12 Oct 2015 19:03:20 +0200 (CEST) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t9CH1pTx025627; Mon, 12 Oct 2015 13:03:19 -0400 Received: from mdwvexchht01.ciena.com (lin1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 1xexwddg40-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Oct 2015 13:03:19 -0400 Received: from VAWVE2K13MBX02.ciena.com (10.4.156.88) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.389.2; Mon, 12 Oct 2015 13:03:18 -0400 Received: from ONWVEXCHHT03.ciena.com (10.128.6.43) by VAWVE2K13MBX02.ciena.com (10.4.156.88) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 12 Oct 2015 13:03:18 -0400 Received: from ONWVEXCHMB01.ciena.com ([10.128.6.18]) by ONWVEXCHHT03.ciena.com ([::1]) with mapi; Mon, 12 Oct 2015 13:03:18 -0400 From: "Yeddula, Avinash" To: "Dumitrescu, Cristian" , "dev@dpdk.org" , "Bly, Mike" Date: Mon, 12 Oct 2015 13:03:16 -0400 Thread-Topic: DPDK hash function related question Thread-Index: AdD0vV0EWrwqSA3rT+Ksi8qmzYCTywAYFeSgA/xM2ZA= Message-ID: References: <3EB4FA525960D640B5BDFFD6A3D89126478D64A1@IRSMSX108.ger.corp.intel.com> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D89126478D64A1@IRSMSX108.ger.corp.intel.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-21876.001 x-tm-as-result: No--39.035200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-12_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510120200 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: Mon, 12 Oct 2015 17:03:20 -0000 Hi Cristian, I have configured the hash function and it compile fine with "warnings". Si= nce librte_hash vs librte_table is 32bit vs 64bit. 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, ui= nt32_t init_val); librte_table library: typedef uint64_t (*rte_table_hash_op_hash) (void *key, uint32_t key_size, u= int64_t seed); I could use one of these hash functions. This is one option, but our first = priority is to use crc hash or cukoo hash. https://github.com/scylladb/dpdk/blob/master/examples/ip_pipeline/pipeline/= hash_func.h We do not want to have those warning in our code. What do you suggest ? Thanks -Avinash -----Original Message----- From: Dumitrescu, Cristian [mailto:cristian.dumitrescu@intel.com]=20 Sent: Tuesday, September 22, 2015 3:05 AM To: Yeddula, Avinash; dev@dpdk.org; Bly, Mike Subject: RE: DPDK hash function related question Hi Avinash, Yes, the hash function is configurable. Are you using a DPDK release older than 2.1? In DPDK we moved away from tes= t_hash to CRC-based hashes. Please take a look at DPDK release 2.1 examples= /ip_pipeline application: in pipeline_flow_classification_be.c, we use CRC-= based hash functions defined in file hash_func.h from the same folder. Regards, Cristian > -----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 >=20 > Hello All, >=20 > I'm DPDK extensible bucket hash in the rte_table library of packet=20 > framework. My question is related to the actual hash function that=20 > computes the hash signature. >=20 > All the available examples have initialized it to test_hash. I do not s= ee any > hash function available in rte_table library , that computes the=20 > actual signature >=20 >=20 >=20 > struct rte_table_hash_ext_params hash_table_params =3D { >=20 > .key_size =3D TABLE_ENTRY_KEY_SIZE, >=20 > .n_keys =3D TABLE_MAX_SIZE, >=20 > .n_buckets =3D TABLE_MAX_BUCKET_COUNT, >=20 > .n_buckets_ext =3D TABLE_MAX_EXT_BUCKET_COUNT, >=20 > .f_hash =3D test_hash, >=20 > .seed =3D 0, >=20 > .signature_offset =3D 0; >=20 > .key_offset =3D __builtin_offsetof(struct metadata_t, tbl_key), >=20 > }; >=20 >=20 >=20 > So, I wanted to use hash functions from DPDK rte_hash library. This is=20 > what I'm doing and looking at the code this looks ok to me. >=20 > I'm at least a week or 2 away from testing this part of the code. I=20 > wanted to confirm that, there is no fundamental flaw in using the DPDK=20 > rte_hash library and rte_table library like this. Could someone confirm t= his please ? >=20 >=20 >=20 > #define DEFAULT_HASH_FUNC rte_hash_crc >=20 >=20 >=20 > struct rte_table_hash_ext_params hash_table_params =3D { >=20 > .key_size =3D TABLE_ENTRY_KEY_SIZE, >=20 > .n_keys =3D TABLE_MAX_SIZE, >=20 > .n_buckets =3D TABLE_MAX_BUCKET_COUNT, >=20 > .n_buckets_ext =3D TABLE_MAX_EXT_BUCKET_COUNT, >=20 > .f_hash =3D DEFAULT_HASH_FUNC , >=20 > .seed =3D 0, >=20 > .signature_offset =3D 0; >=20 > .key_offset =3D __builtin_offsetof(struct metadata_t, tbl_key), >=20 > }; >=20 >=20 >=20 > Thanks >=20 > -Avinash >=20