From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas@monjalon.net> Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id B0F761094 for <dev@dpdk.org>; Tue, 4 Jul 2017 01:26:00 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 528C220C40; Mon, 3 Jul 2017 19:26:00 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 03 Jul 2017 19:26:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=PDCL7u1ovDLAjLg /KJdI/JSkx/vvhpIVWL9vhOWRS70=; b=m7cI7VgTssrmmhQsF4OiKeCBy+Uln7q GS2HxmLp7+ii6gaj95z6+VLqd1zmhU34TM/JGfDvH2Kpt2LZ1lGL29jNCQGI0c2f TY7bSmbdPgQaQ2aFyTOrmRj43Mjf2INZwPUN8rdeLZ1hVTPQ8ewzhi+DRYIt/Z1g Y+aVxfw7+8jI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=PDCL7u1ovDLAjLg/KJdI/JSkx/vvhpIVWL9vhOWRS70=; b=fb1yDQNl QS//mJmyZKRLad/VGmuzPaWkaNzli5qU0df05y/bBcIqNjmhRIezVPcaCirWvHyH oM33BrveLNBiHG9Fn6pYgv2rJgjxsSjj/fdW86hBBGcDDDXgVgHMtJpsY/PrTNoP H3tA4AAjfh1tNiBckt6KXUFLKH7p0DbzRVzkl6XYKiUF1ajIhoomVePQjlIUlypY cCslqfd7Vl9ov2ypat84hxv/0i0zwxbCDQC4E/B5GII3fd7yCDgX5ElYa/TMic6/ E8odldjCzKxLStb+rEig18FcxOHkik/UmKBkrI/hkmbHEiEXulPpEA3M42Ev5AJW 8/KbmPAuqE/18w== X-ME-Sender: <xms:iNJaWRdFTJF7CYvruSRE029vTugo5FyqdE43Lsb2kTlaFMJH0cPjZQ> X-Sasl-enc: VGQ3jbzzTPeeVLsXWUDUepVSsjBLii1u585RoE9bRsMc 1499124360 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 067247E8E4; Mon, 3 Jul 2017 19:26:00 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>, pablo.de.lara.guarch@intel.com Cc: dev@dpdk.org, Jianbo Liu <jianbo.liu@linaro.org>, "jerin.jacob@caviumnetworks.com" <jerin.jacob@caviumnetworks.com>, "ashwin.sekhar@caviumnetworks.com" <ashwin.sekhar@caviumnetworks.com> Date: Tue, 04 Jul 2017 01:25:59 +0200 Message-ID: <1851401.bCM4vaXCYT@xps> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891267BA77E6C@IRSMSX108.ger.corp.intel.com> References: <1495098540-8303-1-git-send-email-jianbo.liu@linaro.org> <4804120.hkK0KHU9aJ@xps> <3EB4FA525960D640B5BDFFD6A3D891267BA77E6C@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 <dev.dpdk.org> List-Unsubscribe: <http://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: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 03 Jul 2017 23:26:01 -0000 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 <jianbo.liu@linaro.org> > > > --- > > > 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. 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.