On Wed, 14 Jan 2004, Clay Haapala wrote:
> This patch against 2.6.1 adds CRC32C checksumming capabilities to the
> crypto routines. The structure of it is based wholly on the existing
> digest (md5) routines, the main difference being that chksums are
> often used in an "accumulator" fashion, effectively requiring one to
> set the seed, and the digest algorithms don't do that.
This looks interesting; do you know of any other chksum algorithms which
might need to be implemented in the kernel?
- james
--
James Morris
<[email protected]>
On Wed, 14 Jan 2004, James Morris stated:
> On Wed, 14 Jan 2004, Clay Haapala wrote:
>
>> This patch against 2.6.1 adds CRC32C checksumming capabilities to
>> the crypto routines. The structure of it is based wholly on the
>> existing digest (md5) routines, the main difference being that
>> chksums are often used in an "accumulator" fashion, effectively
>> requiring one to set the seed, and the digest algorithms don't do
>> that.
>
> This looks interesting; do you know of any other chksum algorithms
> which might need to be implemented in the kernel?
>
I reference the one other user of CRC32C in my code, that would be the
sctp network driver, at this time.
Of course, there is library/crc32, which I did make an attempt to
implement companion code to it, but we really need the "work over
scatterlists" feature of the crypto routines.
I took the design goals the of the library/crc32 routines (flexible
XOR policy, flexible initial values) and tried to allow that in the
crypto chksum routines. CRC32 could be moved into it, but the uses of
CRC32 are often quick accumulation over packet fragments, rather than
computing digests over scatterlists describing would can be many K of
data.
--
Clay Haapala ([email protected]) Cisco Systems SRBU +1 763-398-1056
6450 Wedgwood Rd, Suite 130 Maple Grove MN 55311 PGP: C89240AD
Funny, I didn't think Haliburton was into aerospace.
On Wed, Jan 14, 2004 at 03:31:10PM -0600, Clay Haapala wrote:
> This patch against 2.6.1 adds CRC32C checksumming capabilities to the
> crypto routines. The structure of it is based wholly on the existing
> digest (md5) routines, the main difference being that chksums are
> often used in an "accumulator" fashion, effectively requiring one to
> set the seed, and the digest algorithms don't do that.
>
> CRC32C is a 32-bit CRC variant used by the iSCSI protocol and in other
> drivers. iSCSI uses scatterlists, so it was strongly suggested by the
> SCSI maintainers during reviews of Version 4 of the linux-iscsi driver
> that the code be added to the crypto routines, which operate on
> scatterlists.
>
> Test routines have been added to tcrypt.c.
>
> The linux-iscsi project can be found on SourceForge:
> http://sourceforge.net/projects/linux-iscsi/
Clay!
The cryptoapi stuff seems sensible, but we've already got at least one
copy of the core crc32c code in the kernel at net/sctp/crc32c.c. It'd
be better to work with the sctp folks to push this into lib/crc32.c.
Handling multiple polynomials shouldn't be too painful there.
--
Matt Mackall : http://www.selenic.com : Linux development and consulting
On Wed, 14 Jan 2004, Clay Haapala wrote:
> This patch against 2.6.1 adds CRC32C checksumming capabilities to the
> crypto routines. The structure of it is based wholly on the existing
> digest (md5) routines, the main difference being that chksums are
> often used in an "accumulator" fashion, effectively requiring one to
> set the seed, and the digest algorithms don't do that.
Looks good to me.
- James
--
James Morris
<[email protected]>
On Mon, 19 Jan 2004, James Morris stated:
> On Wed, 14 Jan 2004, Clay Haapala wrote:
>
>> This patch against 2.6.1 adds CRC32C checksumming capabilities to
>> the crypto routines. The structure of it is based wholly on the
>> existing digest (md5) routines, the main difference being that
>> chksums are often used in an "accumulator" fashion, effectively
>> requiring one to set the seed, and the digest algorithms don't do
>> that.
>
> Looks good to me.
>
In other email, Matt Mackall suggested a slightly different
integration with the kernel that would allow more general usage of the
CRC32C. His suggestion was to put the implementation under /lib, next
to the crc32 routines, and make the crypto routine a wrapper that calls
it. Selecting the CRYPTO_CRC32C module would SELECT the lib CRC32C
module, in other words.
The benefit of this would be to allow easy usage by other routines
(with no premption side-affects, a concern Matt has) while still being
there for routines that process scatterlist. And the table/code is
still in one place.
Patch to follow in a day or two, after I can test it. Implementation
was simple.
--
Clay Haapala ([email protected]) Cisco Systems SRBU +1 763-398-1056
6450 Wedgwood Rd, Suite 130 Maple Grove MN 55311 PGP: C89240AD
Funny, I didn't think Haliburton was into aerospace.
On Mon, 19 Jan 2004, Clay Haapala wrote:
> In other email, Matt Mackall suggested a slightly different
> integration with the kernel that would allow more general usage of the
> CRC32C. His suggestion was to put the implementation under /lib, next
> to the crc32 routines, and make the crypto routine a wrapper that calls
> it. Selecting the CRYPTO_CRC32C module would SELECT the lib CRC32C
> module, in other words.
>
> The benefit of this would be to allow easy usage by other routines
> (with no premption side-affects, a concern Matt has) while still being
> there for routines that process scatterlist. And the table/code is
> still in one place.
>
> Patch to follow in a day or two, after I can test it. Implementation
> was simple.
Sounds good -- the inflate/deflate algorithms do this as well.
- James
--
James Morris
<[email protected]>