Messages in this thread | | | Subject | Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API. | From | Chris Mason <> | Date | Mon, 04 Aug 2008 09:45:37 -0400 |
| |
On Mon, 2008-08-04 at 11:45 +0100, David Woodhouse wrote: > On Mon, 2008-08-04 at 06:35 -0400, Austin Zhang wrote: > > On Mon, 2008-08-04 at 11:12 +0100, David Woodhouse wrote: > > > You could perhaps just use 'unsigned long' here, to avoid the ifdef. > > Thanks. > > > And it would be nice if we could make libcrc32c use this too, rather > > > than just the 'crypto' users. > > From previous discussing, herbert would like to transfer the libcrc32c > > interface by new crypto because there were few user using the current > > libcrc32c interface. > > Are we deprecating libcrc32c, then? Or just turning it into a wrapper > around the crypto code? >
Long term I'd like to switch btrfs to the crypto api, but right now I'm using libcrc32c.
>From a performance point of view I'm probably reading the crypto API code wrong, but it looks like my choices are to either have a long standing context and use locking around the digest/hash calls to protect internal crypto state, or create a new context every time and take a perf hit while crypto looks up the right module.
Either way it looks slower than just calling good old libcrc32c.
-chris
| |