[dpdk-dev] [PATCH v2 0/4] rte_hash_crc reworked to be platform-independent

Neil Horman nhorman at tuxdriver.com
Mon Nov 17 12:31:10 CET 2014


On Sun, Nov 16, 2014 at 11:59:16PM +0600, Yerden Zhumabekov wrote:
> This is a rework of my previous patches improving performance of rte_hash_crc. In addition, this revision brings a fallback mechanism to ensure that CRC32 hash is calculated regardless of hardware support from CPU (i.e. SSE4.2 intrinsics).
> 
> Summary of changes:
> * added CRC32 software implementation, which is used as a fallback in case SSE4.2 is not available, or if SSE4.2 is intentionally disabled.
> * added rte_hash_crc_set_alg() function to control availability of SSE4.2.
> * added rte_hash_crc_8byte() function to calculate CRC32 on 8-byte operand.
> * reworked rte_hash_crc() function which leverages both versions of CRC32 hash calculation functions with 4 and 8-byte operands.
> 
> Patches were tested on machines either with and without SSE4.2 support. Software implementation seems to be about 15 times slower than SSE4.2-enabled one. Of course, they return identical results.
> 
> Yerden Zhumabekov (4):
>   hash: add software CRC32 implementation
>   hash: add new rte_hash_crc_8byte call
>   hash: add fallback to software CRC32 implementation
>   hash: rte_hash_crc() slices data into 8-byte pieces
> 
>  lib/librte_hash/rte_hash_crc.h |  212 ++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 202 insertions(+), 10 deletions(-)
> 
> -- 
> 1.7.9.5
> 
> 
Functionally this all looks great, but I think you want to add a 5th patch to
the series in which you remove the ifdef SSE4.2 bits from test_hash_perf, since
this makes rte_hash_crc usable in all cases.  Not sure if you would rather just
ditch rte_hash_jhash alltogether, or make testing it a command line runtime
option

Neil



More information about the dev mailing list