On 24 July 2018 at 13:05, David Laight <david.lai...@aculab.com> wrote: > From: Krzysztof Kozlowski >> Sent: 23 July 2018 17:20 >> Use generic kernel CRC32 implementation because it: >> 1. Should be faster (uses lookup tables), > > Are you sure? > The lookup tables are unlikely to be in the data cache and > the 6 cache misses kill performance. > (Not that it particularly matters when setting up multicast hash tables).
Good point, so this statement should be rather "Could be faster"... I did not run any performance tests so this is not backed up by any data. I think the main benefit is rather easier code maintenance by removing duplicated, custom code. >> 2. Removes duplicated CRC generation code, >> 3. Uses well-proven algorithm instead of coding it one more time. > ... >> >> Not tested on hardware. > > Have you verified that the old and new functions give the > same result for a few mac addresses? > It is very easy to use the wrong bits in crc calculations > or generate the output in the wrong bit order. I copied the original code and new one onto a different driver and run this in a loop for thousands of data input (although not all possible MAC combinations). The output was the same. I agree however that real testing would be important. Best regards, Krzysztof
