From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 77524377E for ; Tue, 4 Jul 2017 15:56:00 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2017 06:55:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,307,1496127600"; d="scan'208";a="1190405355" Received: from irsmsx109.ger.corp.intel.com ([163.33.3.23]) by fmsmga002.fm.intel.com with ESMTP; 04 Jul 2017 06:55:57 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.133]) by IRSMSX109.ger.corp.intel.com ([169.254.13.187]) with mapi id 14.03.0319.002; Tue, 4 Jul 2017 14:55:02 +0100 From: "De Lara Guarch, Pablo" To: Thomas Monjalon , "Dumitrescu, Cristian" CC: "dev@dpdk.org" , Jianbo Liu , "jerin.jacob@caviumnetworks.com" , "ashwin.sekhar@caviumnetworks.com" Thread-Topic: [dpdk-dev] [PATCH] examples/ip_pipeline: use crc32 in hash functions for arm64 Thread-Index: AQHS9FLhyKMh5eFzcEyC/FpmeOMo46JCrguAgACV+yA= Date: Tue, 4 Jul 2017 13:55:01 +0000 Message-ID: References: <1495098540-8303-1-git-send-email-jianbo.liu@linaro.org> <4804120.hkK0KHU9aJ@xps> <3EB4FA525960D640B5BDFFD6A3D891267BA77E6C@IRSMSX108.ger.corp.intel.com> <1851401.bCM4vaXCYT@xps> In-Reply-To: <1851401.bCM4vaXCYT@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 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] examples/ip_pipeline: use crc32 in hash functions for arm64 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: Tue, 04 Jul 2017 13:56:01 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Tuesday, July 4, 2017 12:26 AM > To: Dumitrescu, Cristian ; De Lara Guarch, > Pablo > Cc: dev@dpdk.org; Jianbo Liu ; > jerin.jacob@caviumnetworks.com; ashwin.sekhar@caviumnetworks.com > Subject: Re: [dpdk-dev] [PATCH] examples/ip_pipeline: use crc32 in hash > functions for arm64 >=20 > 04/07/2017 01:19, Dumitrescu, Cristian: > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > 18/05/2017 11:09, Jianbo Liu: > > > > Implement the same hash functions with crc32 on arm platform. > > > > > > > > Signed-off-by: Jianbo Liu > > > > --- > > > > examples/ip_pipeline/pipeline/hash_func.h | 2 + > > > > examples/ip_pipeline/pipeline/hash_func_arm64.h | 245 > > > ++++++++++++++++++++++++ > > > > 2 files changed, 247 insertions(+) create mode 100644 > > > > examples/ip_pipeline/pipeline/hash_func_arm64.h > > > > > > I don't understand why this code is in an example. > > > We have some CRC code in librte_hash, librte_net and ip_pipeline. > > > Cristian, Jianbo, > > > does it make sense to move these functions somewhere else? > > > > > > > I think example apps are a great way to propose new hash functions. > > IMO we should encourage the definition/exploration of new hash > functions in our example apps. > > > > These functions are examples of how fast hash functions can be built > using special CPU instructions. > > They have much better performance than e.g. jhash, but their > > properties are largely unknown, as no rigorous study on their > > properties (such as uniform distribution) has been conducted. I have > > seen them providing good performance for the data set I have been > using, but I have no extensive data to support their maturity level. > > > > If somebody is willing to invest the effort in proving them, I would > > be more than happy to see them moved to a library like librte_hash. > > Pablo as maintainer has the choice (I think it is not the first time > > we discuss bout these hash funcs :) ) > > > > As mentioned in one of our deprecation notices, I am actively working > > (not ready for 17.8 unfortunately) to add a key mask parameter to these > functions, so more work on these hash functions is likely to take place. >=20 > OK thanks for the explanation. > I still think we do not need to prove hash for integrating them. > I would be interested to read Pablo's opinion. If these functions are used as hash functions, I would place them in rte_ha= sh. The case where we placed the CRC function in librte_net was because that was not used as a hash function, so it made sense to me placing it there, but in this case, it looks like it is, so I think rte_hash is a valid place (although someone would need to integrate it with the existing CRC hash fun= ction in that library). Thanks, Pablo