[dpdk-dev] [PATCH v5 4/7] hash: add rte_hash_crc_8byte function
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
[dpdk-dev] [PATCH v5 4/7] hash: add rte_hash_crc_8byte function
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
[dpdk-dev] [PATCH v5 4/7] hash: add rte_hash_crc_8byte function
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