From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 508CB7E75 for ; Fri, 14 Nov 2014 01:42:29 +0100 (CET) Received: from [2001:470:8:a08:215:ff:fecc:4872] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Xp57W-0005B8-MI; Thu, 13 Nov 2014 19:52:28 -0500 Date: Thu, 13 Nov 2014 19:52:11 -0500 From: Neil Horman To: Thomas Monjalon Message-ID: <20141114005211.GC14230@localhost.localdomain> References: <1409724351-23786-1-git-send-email-e_zhumabekov@sts.kz> <2916837.QJI9btJm0N@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2916837.QJI9btJm0N@xps13> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/2] rewritten rte_hash_crc() call 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: Fri, 14 Nov 2014 00:42:29 -0000 On Thu, Nov 13, 2014 at 06:33:14PM +0100, Thomas Monjalon wrote: > Any comment on these patches? > > 2014-09-03 12:05, Yerden Zhumabekov: > > As SSE4.2 provides CRC32 instructions with either 32 and 64 bit operands, > > new rte_hash_crc_8byte() call assisted with _mm_crc32_u64 intrinsic may be > > useful. > > > > Then, rte_hash_crc() function is redesigned to take advantage of both 32 > > and 64 bit operands. This improves the function's performance significantly. > > > > Results of my test run on a single CPU core are below. > > > > CPU: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz > > Number of iterations/chunks: 52428800 > > Chunk size: 24 > > rte_hash_crc: 0.379 sec, hash: 0x14c64e11 > > rte_hash_crc_new: 0.253 sec, hash: 0x14c64e11 > > Chunk size: 25 > > rte_hash_crc: 0.442 sec, hash: 0xa9afc779 > > rte_hash_crc_new: 0.316 sec, hash: 0xa9afc779 > > Chunk size: 26 > > rte_hash_crc: 0.442 sec, hash: 0x92f2284b > > rte_hash_crc_new: 0.316 sec, hash: 0x92f2284b > > Chunk size: 27 > > rte_hash_crc: 0.442 sec, hash: 0x7c4655ff > > rte_hash_crc_new: 0.316 sec, hash: 0x7c4655ff > > Chunk size: 28 > > rte_hash_crc: 0.442 sec, hash: 0xf577c6b4 > > rte_hash_crc_new: 0.316 sec, hash: 0xf577c6b4 > > Chunk size: 29 > > rte_hash_crc: 0.505 sec, hash: 0x6e18ba55 > > rte_hash_crc_new: 0.337 sec, hash: 0x6e18ba55 > > Chunk size: 30 > > rte_hash_crc: 0.505 sec, hash: 0x35f07dbb > > rte_hash_crc_new: 0.337 sec, hash: 0x35f07dbb > > Chunk size: 31 > > rte_hash_crc: 0.505 sec, hash: 0x1bf2ee8c > > rte_hash_crc_new: 0.337 sec, hash: 0x1bf2ee8c > > > > Yerden Zhumabekov (2): > > hash: add new rte_hash_crc_8byte call > > hash: rte_hash_crc uses 8- and 4-byte CRC32 intrinsics > > > > lib/librte_hash/rte_hash_crc.h | 47 +++++++++++++++++++++++++++++++++------- > > 1 file changed, 39 insertions(+), 8 deletions(-) > > Yeah, sorry I didn't speak up earlier. I meant to ask if the __mm_crc_u64 intrinsic will emit software emulated versions of the sse4.2 instruction in the event that you build with a config that doesn't enable sse4.2? If not, then NAK, since this will break on the default build. In that event you'll have to modify the new function to do a runtime cpu flags check to either just use the instruction inlined with some asm, or emulate it in software. Neil