From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: RTE CRC hash function Date: Wed, 26 Feb 2014 10:07:44 +0100 Message-ID: <201402261007.44344.thomas.monjalon@6wind.com> References: <6895EAE0CA8DEE40B92D7CA88BB521F332BA572FC0@HQ1-EXCH02.corp.brocade.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: dev-VfR2kkLFssw@public.gmane.org To: Pashupati Kumar Return-path: In-Reply-To: <6895EAE0CA8DEE40B92D7CA88BB521F332BA572FC0-7bu+sH2UtuFYKLnPCdnYV+N5nnCVAcvGQQ4Iyu8u01E@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 10/12/2013 04:17, Pashupati Kumar: > I am looking at the DPDK implementation for the CRC hash function using > Intel intrinsics. Shouldn't the order of the arguments being passed to > _mm_crc32_u32 be reversed ? http://dpdk.org/doc/api/rte__hash__crc_8h.html > > For a quick reference, here is the code with Actual and Modified calls. > static inline uint32_t > rte_hash_crc_4byte(uint32_t data, uint32_t init_val) > { > Actual > return _mm_crc32_u32(data, init_val); > Modified > return _mm_crc32_u32(init_val, data); > } It is now fixed by this commit: http://dpdk.org/browse/dpdk/commit/?id=65b0663b7f32e4157b71dc14a016215e1bc63157 Thanks for reporting -- Thomas