[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7d2ad97c-6a0e-4113-9f30-c30b5db7a028@lkcamp.dev>
Date: Sun, 29 Sep 2024 21:57:45 -0300
From: Vinicius Peixoto <vpeixoto@...amp.dev>
To: David Laight <David.Laight@...LAB.COM>,
André Almeida <andrealmeid@...eup.net>
Cc: Brendan Higgins <brendan.higgins@...ux.dev>,
"~lkcamp/patches@...ts.sr.ht" <~lkcamp/patches@...ts.sr.ht>,
Rae Moar <rmoar@...gle.com>, David Gow <davidgow@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"kunit-dev@...glegroups.com" <kunit-dev@...glegroups.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH 0/1] Add KUnit tests for lib/crc16.c
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)
Powered by blists - more mailing lists