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

[Yerden Zhumabekov <e_zhumabekov@sts.kz>]

17.11.2014 17:31, Neil Horman пишет:
> 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

Meanwhile, I've borrowed some Intel's code (BSD licensed) for CRC32 sw
algorithm, it runs 4 times faster sacrificing memory (2K) for additional
lookup tables. I'd like to include it as well. As for test_hash_perf,
I'll look at it.
Should I just send new series over as 'v3'? Any approval/disapproval for
the current series?

-- 
Sincerely,

Yerden Zhumabekov
State Technical Service
Astana, KZ