... > 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 - 2024 Red Hat, Inc.