...
> The checksums for the randomly-generated test cases were calculated
> using a reference implementation [1] and this test compares them against
> the values yielded by the kernel's implementation.
I'd just use a naïve implementation - doesn't really matter
if it is a bit slow.
Slow is relative - this code only takes 35ms to crc-64 over 5MB of data.
{
volatile const uint32_t *r = (const void *)buf;
for (crc = 0; r < (const uint32_t *)buf_end; r++) {
uint64_t val = le32toh(*r);
crc ^= bswap64(val);
for (i = 0; i < 32; i++) {
if (crc & (1ull << 63))
crc = (crc << 1) ^ 0x42f0e1eba9ea3693ull;
else
crc = crc << 1;
}
}
}
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Hi David,
On 9/26/24 13:21, David Laight wrote:
> ...
>> The checksums for the randomly-generated test cases were calculated
>> using a reference implementation [1] and this test compares them against
>> the values yielded by the kernel's implementation.
>
> I'd just use a naïve implementation - doesn't really matter
> if it is a bit slow.
Thanks for the feedback. I agree that it makes more sense to use a naive
implementation to validate the results from the kernel's crc16 instead
of having a table of pre-computed results. I will include in v2 a
bog-standard implementation of crc16 similar to yours (using a loop
instead of a lookup table) to validate the results.
Thanks,
Vinicius
>
> Slow is relative - this code only takes 35ms to crc-64 over 5MB of data.
>
> {
> volatile const uint32_t *r = (const void *)buf;
> for (crc = 0; r < (const uint32_t *)buf_end; r++) {
> uint64_t val = le32toh(*r);
> crc ^= bswap64(val);
> for (i = 0; i < 32; i++) {
> if (crc & (1ull << 63))
> crc = (crc << 1) ^ 0x42f0e1eba9ea3693ull;
> else
> crc = crc << 1;
> }
> }
> }
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
© 2016 - 2026 Red Hat, Inc.