From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mgw.gov.kz (mgw.gov.kz [89.218.88.242]) by dpdk.org (Postfix) with ESMTP id 8A18D58D9 for ; Fri, 21 Nov 2014 12:16:03 +0100 (CET) Received: from mgw.gov.kz (mx.ctsat.kz [178.89.4.95]) by mgw.gov.kz with ESMTP id sALBQV1N003707-sALBQV1P003707 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Nov 2014 17:26:32 +0600 Received: from EXCASHUB1.rgp.local (192.168.40.51) by EdgeForefront.rgp.local (192.168.40.59) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 21 Nov 2014 17:26:18 +0600 Received: from [192.168.35.15] (192.168.35.15) by excashub1.rgp.local (192.168.40.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 21 Nov 2014 17:26:32 +0600 Message-ID: <546F215A.8060608@sts.kz> Date: Fri, 21 Nov 2014 17:26:18 +0600 From: Yerden Zhumabekov User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Neil Horman References: <1409724351-23786-1-git-send-email-e_zhumabekov@sts.kz> <5bc163e39a2e8176f7e0b424c70bb051d2f5a0a8.1416459284.git.e_zhumabekov@sts.kz> <20141121112242.GA20661@hmsreliant.think-freely.org> In-Reply-To: <20141121112242.GA20661@hmsreliant.think-freely.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [192.168.35.15] X-FEAS-SYSTEM-WL: e_zhumabekov@sts.kz Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v5 4/7] hash: add rte_hash_crc_8byte function 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, 21 Nov 2014 11:16:04 -0000 21.11.2014 17:22, Neil Horman пишет: > On Thu, Nov 20, 2014 at 11:16:34AM +0600, Yerden Zhumabekov wrote: >> SSE4.2 provides CRC32 intrinsic with 8-byte operand. >> >> Signed-off-by: Yerden Zhumabekov >> --- >> lib/librte_hash/rte_hash_crc.h | 16 ++++++++++++++++ >> 1 file changed, 16 insertions(+) >> >> diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash/rte_hash_crc.h >> index cd28833..2c8ec99 100644 >> --- a/lib/librte_hash/rte_hash_crc.h >> +++ b/lib/librte_hash/rte_hash_crc.h >> @@ -413,6 +413,22 @@ rte_hash_crc_4byte(uint32_t data, uint32_t init_val) >> } >> >> /** >> + * Use single crc32 instruction to perform a hash on a 8 byte value. >> + * >> + * @param data >> + * Data to perform hash on. >> + * @param init_val >> + * Value to initialise hash generator. >> + * @return >> + * 32bit calculated hash value. >> + */ >> +static inline uint32_t >> +rte_hash_crc_8byte(uint64_t data, uint32_t init_val) >> +{ >> + return crc32c_sse42_u64(data, init_val); >> +} >> + >> +/** >> * Use crc32 instruction to perform a hash. >> * >> * @param data >> -- >> 1.7.9.5 >> >> > I'm sorry, it may be early here, so I may be missing something. The assembly > implementations look great, but if a user calls rte_hash_crc_8byte on a system > that doesn't support ss342, how do they wind up getting into the software crc > implementation given what you have above? > Neil After applying patch 4 out of 7 - there's no fall back. Fall back to SW crc32 algorithm is in patch 5/7. Moreover, after patch 5/7 there's a detection if the platform supports 64-bit, otherwise 64-bit operand support is mimicked using two 32-bit function calls. -- Sincerely, Yerden Zhumabekov State Technical Service Astana, KZ