Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
* David Woodhouse | 2008-08-04 11:12:05 [+0100]:
>On Mon, 2008-08-04 at 05:35 -0400, Austin Zhang wrote:
>> +u32 __pure crc32c_intel_le_hw(u32 crc, unsigned char const *p, size_t
>> len)
>> +{
>> + unsigned int iquotient = len / SCALE_F;
>> + unsigned int iremainder = len % SCALE_F;
>> +#ifdef CONFIG_X86_64
>> + u64 *ptmp = (u64 *)p;
>> +#else
>> + u32 *ptmp = (u32 *)p;
>> +#endif
>
>You could perhaps just use 'unsigned long' here, to avoid the ifdef.
>
>And it would be nice if we could make libcrc32c use this too, rather
>than just the 'crypto' users.
I'm not sure if I remeber correctly but I thing Herbert was planning to
convert all users over to the crypto API to avoid compile time
dependency.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, 2008-08-04 at 12:25 +0200, Sebastian Siewior wrote: > * David Woodhouse | 2008-08-04 11:12:05 [+0100]: > >And it would be nice if we could make libcrc32c use this too, rather > >than just the 'crypto' users. > > I'm not sure if I remeber correctly but I thing Herbert was planning to > convert all users over to the crypto API to avoid compile time > dependency. That's one way of doing it, although it seems a little bit like overkill in this particular case. -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, 2008-08-04 at 05:35 -0400, Austin Zhang wrote:
> +u32 __pure crc32c_intel_le_hw(u32 crc, unsigned char const *p, size_t
> len)
> +{
> + unsigned int iquotient = len / SCALE_F;
> + unsigned int iremainder = len % SCALE_F;
> +#ifdef CONFIG_X86_64
> + u64 *ptmp = (u64 *)p;
> +#else
> + u32 *ptmp = (u32 *)p;
> +#endif
You could perhaps just use 'unsigned long' here, to avoid the ifdef.
And it would be nice if we could make libcrc32c use this too, rather
than just the 'crypto' users.
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
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. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, Aug 04, 2008 at 12:25:57PM +0200, Sebastian Siewior wrote:
>
> I'm not sure if I remeber correctly but I thing Herbert was planning to
> convert all users over to the crypto API to avoid compile time
> dependency.
Yes that's the plan. I've been busy with the crypto testing
stuff but I'll get onto this soon.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, 2008-08-04 at 11:45 +0100, David Woodhouse wrote: > Are we deprecating libcrc32c, then? Or just turning it into a wrapper > around the crypto code? Maybe I can pick up crc32c_intel_le_hw_byte and crc32c_intel_le_hw into one arch-related file and make the current new crypto interface and libcrc32c call it. > Either way, does it really make sense to force all crc32 users to pull > in the whole crypto framework? Some may get fractious about that... If there were really few (or no) user using that previous interface, it will be reasonable to merge the crc32c totally into crypto subsystem as a digest method. And I remembered Herbert had mentioned he will convert those previous interface calling to new crypto API. For the crc32c, he had done for it. BTW, why did I always got each email on this thread twice:(? (the same email twice) -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
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? Either way, does it really make sense to force all crc32 users to pull in the whole crypto framework? Some may get fractious about that... -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, 2008-08-04 at 06:58 -0400, Austin Zhang wrote: > BTW, why did I always got each email on this thread twice:(? (the same > email twice) You're probably subscribed to the linux-kernel list, and you're also being Cc'd directly. Normally, your filters should notice the copy which has a Return-Path: matching '[EMAIL PROTECTED]', and put that into your lkml folder with a few hundred other messages each day -- while the copy which is direct will still have the original sender, and would go into your inbox where you'll see it. -- dwmw2 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, Aug 04, 2008 at 11:45:26AM +0100, David Woodhouse wrote:
>
> Are we deprecating libcrc32c, then? Or just turning it into a wrapper
> around the crypto code?
It will be removed.
> Either way, does it really make sense to force all crc32 users to pull
> in the whole crypto framework? Some may get fractious about that...
There only three crc32c users in the kernel tree and the crypto
interface will serve the perfectly.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, 2008-08-04 at 05:35 -0400, Austin Zhang wrote:
> +static int crc32c_intel_cra_init(struct crypto_tfm *tfm)
> +{
> + u32 *key = crypto_tfm_ctx(tfm);
> +
> + *key = ~0;
> +
> + tfm->crt_ahash.reqsize = sizeof(u32);
> +
> + if (cpu_has_xmm4_2)
> + return 0;
> + else
> + return -1;
> +}
...
> +static int __init crc32c_intel_mod_init(void)
> +{
> + return crypto_register_alg(&alg);
> +}
> +
Am I missing something here, or are you registering the crypto algorithm
_unconditionally_ and then just causing init requests for it to fail on
older hardware? Wouldn't it be better to register the driver _only_
when the hardware is capable? Or at least "if at least one cpu is
capable".
> --- linux-2.6/crypto/Kconfig 2008-08-04 01:08:00.0 -0400
> +++ linux-2.6-patch/crypto/Kconfig2008-08-04 01:59:00.0 -0400
> @@ -221,6 +221,17 @@ config CRYPTO_CRC32C
> See Castagnoli93. This implementation uses lib/libcrc32c.
>Module will be crc32c.
>
> +config CRYPTO_CRC32C_INTEL
> +tristate "CRC32c INTEL hardware acceleration"
> +select CRYPTO_HASH
> +help
> + In Intel processor with SSE4.2 supported, the processor will
> + support CRC32C implemetation using hardware accelerated CRC32
> + instruction. This option will create 'crc32c-intel' module,
> + which will enable any routine to use the CRC32 instruction to
> + gain performance compared with software implementation.
> + Module will be crc32c-intel.
> +
> config CRYPTO_MD4
> tristate "MD4 digest algorithm"
> select CRYPTO_ALGAPI
I think that should depend on CONFIG_X86?
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, Aug 04, 2008 at 03:13:34PM +0100, David Woodhouse wrote:
>
> > +static int __init crc32c_intel_mod_init(void)
> > +{
> > + return crypto_register_alg(&alg);
> > +}
> > +
>
> Am I missing something here, or are you registering the crypto algorithm
> _unconditionally_ and then just causing init requests for it to fail on
> older hardware? Wouldn't it be better to register the driver _only_
> when the hardware is capable? Or at least "if at least one cpu is
> capable".
Yes I think this is a show-stopper :)
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, Aug 04, 2008 at 05:35:07AM -0400, Austin Zhang wrote:
>
> +static int crc32c_intel_cra_init(struct crypto_tfm *tfm)
> +{
> + u32 *key = crypto_tfm_ctx(tfm);
> +
> + *key = ~0;
> +
> + tfm->crt_ahash.reqsize = sizeof(u32);
> +
> + if (cpu_has_xmm4_2)
> + return 0;
> + else
> + return -1;
> +}
This check needs to be moved to the module init function and
if it fails the module should not register the algorithm.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, Aug 04, 2008 at 05:35:07AM -0400, Austin Zhang wrote:
>
> +config CRYPTO_CRC32C_INTEL
> +tristate "CRC32c INTEL hardware acceleration"
> +select CRYPTO_HASH
You need some sort of a dependency here. See what the other
assembly algorithms do it.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, 4 Aug 2008 22:04:35 +0800 Herbert Xu <[EMAIL PROTECTED]> wrote: > There only three crc32c users in the kernel tree and the crypto > interface will serve the perfectly. isn't it a bit heavy for something as simple as a crc? (which after all is one instruction now ;0) -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, 2008-08-04 at 07:20 -0700, Arjan van de Ven wrote: > On Mon, 4 Aug 2008 22:04:35 +0800 > Herbert Xu <[EMAIL PROTECTED]> wrote: > > > There only three crc32c users in the kernel tree and the crypto > > interface will serve the perfectly. > > isn't it a bit heavy for something as simple as a crc? > (which after all is one instruction now ;0) It does seem that way. For users who care about 'bloat' and are _only_ interested in crc32, it's yet another chunk of extra infrastructure which offers no benefit to them. And even for people who don't care about that, it doesn't look particularly good. It looks like btrfs would need either to keep setting up a crypto context and then tearing it down, or have a pool of long-standing contexts and do some kind of locking on them -- neither of which seem particularly optimal compared with just calling into libcrc32c. We can't even set up one context per cpu and disable preempt while we use it, can we? The routines are allowed to sleep? (Although I have to admit I do like the fact that it'd only be available through EXPORT_SYMBOL_GPL if we do force people to use the crypto API...) -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, Aug 04, 2008 at 03:49:01PM +0100, David Woodhouse wrote:
>
> And even for people who don't care about that, it doesn't look
> particularly good. It looks like btrfs would need either to keep setting
> up a crypto context and then tearing it down, or have a pool of
> long-standing contexts and do some kind of locking on them -- neither of
> which seem particularly optimal compared with just calling into
> libcrc32c.
No you don't have to set things up every time you use crc32c.
The crypto interface lets you have a single tfm that can be
used by multiple users simultaneously. For ahash algorithms
all the state is stored in the request which can stay on the
stack.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Mon, 4 Aug 2008 22:04:35 +0800
> Herbert Xu <[EMAIL PROTECTED]> wrote:
>
>> There only three crc32c users in the kernel tree and the crypto
>> interface will serve the perfectly.
>
> isn't it a bit heavy for something as simple as a crc?
> (which after all is one instruction now ;0)
Well AES on the PadLock is also a single instruction and nobody
has ever complained :)
Seriously, the crypto code is extremely small on the data path.
The heaviest part is the indirect function call but you have to
have that in order to support multiple implementations cleanly.
All the fat is on the control path, i.e., tfm allocation. For
crc32c you only need a single tfm since all the state is stored
in the request object.
Note that you should ignore the existing crc32c user, iSCSI as
it was written before the new crypto hash interface was available.
I will be converting it along with the other two crc32c users. to
the new ahash interface.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
Chris Mason <[EMAIL PROTECTED]> wrote: > >>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. You're looking at the old hash interface. New users should use the ahash interface which was only recently added to the kernel. It lets you store the state in the request object which you pass to the algorithm on every call. This means that you only need one tfm in the entire system for crc32c. BTW, don't let the a in ahash intimidate you. It's meant to support synchronous implementations such as the Intel instruction just as well as asynchronous ones. And if you're still not convinced here is the benchmark on the digest_null algorithm: testing speed of stub_digest_null test 0 ( 16 byte blocks, 16 bytes per update, 1 updates):190 cycles/operation, 11 cycles/byte test 1 ( 64 byte blocks, 16 bytes per update, 4 updates):367 cycles/operation,5 cycles/byte test 2 ( 64 byte blocks, 64 bytes per update, 1 updates):192 cycles/operation,3 cycles/byte test 3 ( 256 byte blocks, 16 bytes per update, 16 updates): 1006 cycles/operation,3 cycles/byte test 4 ( 256 byte blocks, 64 bytes per update, 4 updates):378 cycles/operation,1 cycles/byte test 5 ( 256 byte blocks, 256 bytes per update, 1 updates):191 cycles/operation,0 cycles/byte test 6 ( 1024 byte blocks, 16 bytes per update, 64 updates): 3557 cycles/operation,3 cycles/byte test 7 ( 1024 byte blocks, 256 bytes per update, 4 updates):365 cycles/operation,0 cycles/byte test 8 ( 1024 byte blocks, 1024 bytes per update, 1 updates):191 cycles/operation,0 cycles/byte test 9 ( 2048 byte blocks, 16 bytes per update, 128 updates): 6903 cycles/operation,3 cycles/byte test 10 ( 2048 byte blocks, 256 bytes per update, 8 updates):574 cycles/operation,0 cycles/byte test 11 ( 2048 byte blocks, 1024 bytes per update, 2 updates):259 cycles/operation,0 cycles/byte test 12 ( 2048 byte blocks, 2048 bytes per update, 1 updates):192 cycles/operation,0 cycles/byte test 13 ( 4096 byte blocks, 16 bytes per update, 256 updates): 13626 cycles/operation,3 cycles/byte test 14 ( 4096 byte blocks, 256 bytes per update, 16 updates): 1008 cycles/operation,0 cycles/byte test 15 ( 4096 byte blocks, 1024 bytes per update, 4 updates):370 cycles/operation,0 cycles/byte test 16 ( 4096 byte blocks, 4096 bytes per update, 1 updates):193 cycles/operation,0 cycles/byte test 17 ( 8192 byte blocks, 16 bytes per update, 512 updates): 27042 cycles/operation,3 cycles/byte test 18 ( 8192 byte blocks, 256 bytes per update, 32 updates): 1854 cycles/operation,0 cycles/byte test 19 ( 8192 byte blocks, 1024 bytes per update, 8 updates):576 cycles/operation,0 cycles/byte test 20 ( 8192 byte blocks, 4096 bytes per update, 2 updates):253 cycles/operation,0 cycles/byte test 21 ( 8192 byte blocks, 8192 bytes per update, 1 updates):241 cycles/operation,0 cycles/byte This is a dry run with a digest_null where all the functions are stubbed out (i.e., just a return 0). So this measures the overhead of the benchmark itself. Now with a run over a digest_null that simply touches all the data: testing speed of digest_null test 0 ( 16 byte blocks, 16 bytes per update, 1 updates):193 cycles/operation, 12 cycles/byte test 1 ( 64 byte blocks, 16 bytes per update, 4 updates):369 cycles/operation,5 cycles/byte test 2 ( 64 byte blocks, 64 bytes per update, 1 updates):193 cycles/operation,3 cycles/byte test 3 ( 256 byte blocks, 16 bytes per update, 16 updates): 1010 cycles/operation,3 cycles/byte test 4 ( 256 byte blocks, 64 bytes per update, 4 updates):364 cycles/operation,1 cycles/byte test 5 ( 256 byte blocks, 256 bytes per update, 1 updates):191 cycles/operation,0 cycles/byte test 6 ( 1024 byte blocks, 16 bytes per update, 64 updates): 3538 cycles/operation,3 cycles/byte test 7 ( 1024 byte blocks, 256 bytes per update, 4 updates):370 cycles/operation,0 cycles/byte test 8 ( 1024 byte blocks, 1024 bytes per update, 1 updates):192 cycles/operation,0 cycles/byte test 9 ( 2048 byte blocks, 16 bytes per update, 128 updates): 6927 cycles/operation,3 cycles/byte test 10 ( 2048 byte blocks, 256 bytes per update, 8 updates):576 cycles/operation,0 cycles/byte test 11 ( 2048 byte blocks, 1024 bytes per update, 2 updates):259 cycles/operation,0 cycles/byte test 12 ( 2048 byte blocks, 2048 bytes per update, 1 updates):192 cycles/operation,0 cycles/byt
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, 2008-08-04 at 23:42 +0800, Herbert Xu wrote: > Chris Mason <[EMAIL PROTECTED]> wrote: > > > >>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. > > You're looking at the old hash interface. New users should use the > ahash interface which was only recently added to the kernel. It > lets you store the state in the request object which you pass to > the algorithm on every call. This means that you only need one > tfm in the entire system for crc32c. > Great to hear, that solves my main concern then. There is still the embedded argument against needing all of crypto api just for libcrc32c. It does make sense to me to have a libcrc32c that does the HW detection and uses HW assist when present, and just have the cypto api call that. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
Chris Mason <[EMAIL PROTECTED]> wrote:
>
> Great to hear, that solves my main concern then. There is still the
> embedded argument against needing all of crypto api just for libcrc32c.
The existing users are iSCSI, SCTP, Infiniband, all of which are
clearly crucial in the embedded space :)
> It does make sense to me to have a libcrc32c that does the HW detection
> and uses HW assist when present, and just have the cypto api call that.
Well then you're going to have to do the check on every call.
Seriously, I'm happy to trim off any fat from the crypto API for the
embedded space. For a start, if you only needed hashing then we
could do without the legacy cipher/compress support. That shaves
off 800 bytes on i386. There is also still some legacy code in
api.c itself. Getting rid of them should get us to around 2K.
On the other hand, one of the advantages of doing it through the
crypto API is that this kind of selection is useful for quite a
few operations, e.g., xor or even memcpy.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Tue, 05 Aug 2008 00:45:34 +0800 Herbert Xu <[EMAIL PROTECTED]> wrote: > On the other hand, one of the advantages of doing it through the > crypto API is that this kind of selection is useful for quite a > few operations, e.g., xor or even memcpy. well you still have that indirect function call for libcrc32 we could alternatives() that... -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, Aug 04, 2008 at 10:06:05AM -0700, Arjan van de Ven wrote:
>
> well you still have that indirect function call
>
> for libcrc32 we could alternatives() that...
I don't see why you couldn't do that for the crypto API too
if you wanted to. That way it would benefit all crypto users
rather than just the crc32c (note the extra c) users.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Tue, Aug 05, 2008 at 01:10:17AM +0800, Herbert Xu wrote:
>
> I don't see why you couldn't do that for the crypto API too
> if you wanted to. That way it would benefit all crypto users
> rather than just the crc32c (note the extra c) users.
Anyway, the point here is the crc32c is nothing special. It's
just one out of many algorithms that has/will have hardware
acceleration support.
Rather than doing ad-hoc implementations and optimising that
whenever such a thing pops up, let's spend our effort in creating
a common platform that can be reused.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, 04 Aug 2008 05:35:07 -0400 Austin Zhang wrote: > diff -Naurp linux-2.6/crypto/Kconfig linux-2.6-patch/crypto/Kconfig > --- linux-2.6/crypto/Kconfig 2008-08-04 01:08:00.0 -0400 > +++ linux-2.6-patch/crypto/Kconfig2008-08-04 01:59:00.0 -0400 > @@ -221,6 +221,17 @@ config CRYPTO_CRC32C > See Castagnoli93. This implementation uses lib/libcrc32c. >Module will be crc32c. > > +config CRYPTO_CRC32C_INTEL > +tristate "CRC32c INTEL hardware acceleration" > +select CRYPTO_HASH > +help > + In Intel processor with SSE4.2 supported, the processor will > + support CRC32C implemetation using hardware accelerated CRC32 implementation > + instruction. This option will create 'crc32c-intel' module, > + which will enable any routine to use the CRC32 instruction to > + gain performance compared with software implementation. > + Module will be crc32c-intel. and don't end lines with spaces... --- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, Aug 4, 2008 at 5:42 PM, Herbert Xu <[EMAIL PROTECTED]> wrote: > Chris Mason <[EMAIL PROTECTED]> wrote: >> >>>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. > > You're looking at the old hash interface. New users should use the > ahash interface which was only recently added to the kernel. It > lets you store the state in the request object which you pass to > the algorithm on every call. This means that you only need one > tfm in the entire system for crc32c. > > BTW, don't let the a in ahash intimidate you. It's meant to support > synchronous implementations such as the Intel instruction just as > well as asynchronous ones. Since I couldn't find any ahash user in the tree (outside of tcrypt.c), can you provide some example source code as to how to use it (especially synchonously). For example the code for the digest_null testing would be fine. regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
Benoit Boissinot <[EMAIL PROTECTED]> wrote:
>
> Since I couldn't find any ahash user in the tree (outside of tcrypt.c), can
> you
> provide some example source code as to how to use it (especially
> synchonously).
>
> For example the code for the digest_null testing would be fine.
Sure, here is the async hash speed test. I haven't pushed it
yet because I'm thinking of picking up on David Howells' idea
of creating a sync hash interface that doesn't use scatterlists.
Note that you'll need the appended patch for this to compile as
the partial ahash functions were missing prototypes.
static int test_hash_cycles(struct ahash_request *req, struct scatterlist *sg,
int blen, int plen, char *out)
{
unsigned long cycles = 0;
int i, pcount;
int ret;
if (plen == blen)
return test_hash_cycles_digest(req, sg, blen, out);
ahash_request_set_crypt(req, sg, out, plen);
local_bh_disable();
local_irq_disable();
/* Warm-up run. */
for (i = 0; i < 4; i++) {
ret = crypto_ahash_init(req);
if (ret)
goto out;
for (pcount = 0; pcount < blen; pcount += plen) {
ret = crypto_ahash_update(req);
if (ret)
goto out;
}
ret = crypto_ahash_final(req);
if (ret)
goto out;
}
/* The real thing. */
for (i = 0; i < 8; i++) {
cycles_t start, end;
start = get_cycles();
ret = crypto_ahash_init(req);
if (ret)
goto out;
for (pcount = 0; pcount < blen; pcount += plen) {
ret = crypto_ahash_update(req);
if (ret)
goto out;
}
ret = crypto_ahash_final(req);
if (ret)
goto out;
end = get_cycles();
cycles += end - start;
}
out:
local_irq_enable();
local_bh_enable();
if (ret)
return ret;
printk("%6lu cycles/operation, %4lu cycles/byte\n",
cycles / 8, cycles / (8 * blen));
return 0;
}
static void test_hash_speed(const char *algo, unsigned int sec,
struct hash_speed *speed)
{
struct scatterlist sg[TVMEMSIZE];
struct crypto_ahash *tfm;
char output[1024];
int i;
int ret;
printk("\ntesting speed of %s\n", algo);
tfm = crypto_alloc_ahash(algo, 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(tfm)) {
printk("failed to load transform for %s: %ld\n", algo,
PTR_ERR(tfm));
return;
}
{
struct {
struct ahash_request req;
char ctx[crypto_ahash_reqsize(tfm)];
} req;
ahash_request_set_tfm(&req.req, tfm);
ahash_request_set_callback(&req.req, 0, NULL, NULL);
if (crypto_ahash_digestsize(tfm) > sizeof(output)) {
printk("digestsize(%u) > outputbuffer(%zu)\n",
crypto_ahash_digestsize(tfm), sizeof(output));
goto out;
}
sg_init_table(sg, TVMEMSIZE);
for (i = 0; i < TVMEMSIZE; i++) {
sg_set_buf(sg + i, tvmem[i], PAGE_SIZE);
memset(tvmem[i], 0xff, PAGE_SIZE);
}
for (i = 0; speed[i].blen != 0; i++) {
if (speed[i].blen > TVMEMSIZE * PAGE_SIZE) {
printk("template (%u) too big for tvmem (%lu)\n",
speed[i].blen, TVMEMSIZE * PAGE_SIZE);
goto out;
}
printk("test%3u (%5u byte blocks,%5u bytes per update,%4u
updates): ",
i, speed[i].blen, speed[i].plen, speed[i].blen /
speed[i].plen);
if (sec)
ret = test_hash_jiffies(&req.req, sg, speed[i].blen,
speed[i].plen, output, sec);
else
ret = test_hash_cycles(&req.req, sg, speed[i].blen,
speed[i].plen, output);
if (ret) {
printk("hashing failed ret=%d\n", ret);
break;
}
}
}
out:
crypto_free_ahash(tfm);
}
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index d12498e..ee48ef8 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
Herbert Xu wrote: On Tue, Aug 05, 2008 at 01:10:17AM +0800, Herbert Xu wrote: I don't see why you couldn't do that for the crypto API too if you wanted to. That way it would benefit all crypto users rather than just the crc32c (note the extra c) users. Anyway, the point here is the crc32c is nothing special. It's just one out of many algorithms that has/will have hardware acceleration support. Rather than doing ad-hoc implementations and optimising that whenever such a thing pops up, let's spend our effort in creating a common platform that can be reused. How about making crc32c an inline function then? On processors that have this feature, this compiles to that single instruction, plus whatever setup it needs. Nice and efficient. On other processors, either inline the algorithm or inline a call to an out of line function, depending on how bulky this is. Similiar for any other functions that may or may not have hw support. Helge Hafting -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Tue, Aug 05, 2008 at 05:59:11AM -0400, Austin Zhang wrote:
>
> How about:
> +config CRYPTO_CRC32C_INTEL
> +tristate "CRC32c INTEL hardware acceleration"
> + depends on X86
> +select CRYPTO_ALGAPI
> +help
> + In Intel processor with SSE4.2 supported, the processor will
> ..
>
> It should only depend on X86.
Yes that looks good.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, 2008-08-04 at 10:27 -0700, Randy Dunlap wrote: > On Mon, 04 Aug 2008 05:35:07 -0400 Austin Zhang wrote: > > > diff -Naurp linux-2.6/crypto/Kconfig linux-2.6-patch/crypto/Kconfig > > --- linux-2.6/crypto/Kconfig2008-08-04 01:08:00.0 -0400 > > +++ linux-2.6-patch/crypto/Kconfig 2008-08-04 01:59:00.0 -0400 > > @@ -221,6 +221,17 @@ config CRYPTO_CRC32C > > See Castagnoli93. This implementation uses lib/libcrc32c. > >Module will be crc32c. > > > > +config CRYPTO_CRC32C_INTEL > > +tristate "CRC32c INTEL hardware acceleration" > > +select CRYPTO_HASH > > +help > > + In Intel processor with SSE4.2 supported, the processor will > > + support CRC32C implemetation using hardware accelerated CRC32 > > implementation > > > + instruction. This option will create 'crc32c-intel' module, > > + which will enable any routine to use the CRC32 instruction to > > + gain performance compared with software implementation. > > + Module will be crc32c-intel. > > and don't end lines with spaces... > > Thanks a lot:) -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, 2008-08-04 at 22:19 +0800, Herbert Xu wrote: > On Mon, Aug 04, 2008 at 05:35:07AM -0400, Austin Zhang wrote: > > > > +config CRYPTO_CRC32C_INTEL > > +tristate "CRC32c INTEL hardware acceleration" > > +select CRYPTO_HASH > > You need some sort of a dependency here. See what the other > assembly algorithms do it. > > Cheers, How about: +config CRYPTO_CRC32C_INTEL +tristate "CRC32c INTEL hardware acceleration" + depends on X86 +select CRYPTO_ALGAPI +help + In Intel processor with SSE4.2 supported, the processor will .. It should only depend on X86. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Mon, 2008-08-04 at 15:13 +0100, David Woodhouse wrote: > Am I missing something here, or are you registering the crypto algorithm > _unconditionally_ and then just causing init requests for it to fail on > older hardware? Wouldn't it be better to register the driver _only_ > when the hardware is capable? Or at least "if at least one cpu is > capable". Thanks, I will move it to module init. > I think that should depend on CONFIG_X86? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API.
On Tue, Aug 05, 2008 at 01:10:25PM +0200, Helge Hafting wrote:
>
> How about making crc32c an inline function then?
> On processors that have this feature, this compiles to that single
> instruction, plus whatever setup it needs. Nice and efficient.
> On other processors, either inline the algorithm or inline
> a call to an out of line function, depending on how bulky this is.
Please read the thread carefully. Being a single instruction
is nothing special. The same thing applies for other algorithms
too, e.g., AES is also just a single instruction with the VIA
PadLock (and Intel in future).
The crypto API has handled this just fine.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API -V2.
Hi Austin:
On Tue, Aug 05, 2008 at 07:56:43AM -0400, Austin Zhang wrote:
> Revised by comments:
> Move hardware feature detect into module init;
> Revise dependency in Kconfig;
> Revise variable type;
> Add information output while module loading failed;
>
>
> >From NHM processor onward, Intel processors can support hardware
> accelerated
> CRC32c algorithm with the new CRC32 instruction in SSE 4.2 instruction
> set.
> The patch detects the availability of the feature, and chooses the most
> proper
> way to calculate CRC32c checksum.
> Byte code instructions are used for compiler compatibility.
> No MMX / XMM registers is involved in the implementation.
>
> Signed-off-by: Austin Zhang <[EMAIL PROTECTED]>
> Signed-off-by: Kent Liu <[EMAIL PROTECTED]>
I tried to apply your patch but it doesn't work:
$ git apply --check --whitespace=error-all ~/p
fatal: patch fragment without header at line 34: @@ -0,0 +1,190 @@
$
Looks like your mail client has folded all the lines.
> +u32 crc32c_intel_le_hw_byte(u32 crc, unsigned char const *data, size_t
> length)
While you're fixing that up please add a static here.
> +u32 __pure crc32c_intel_le_hw(u32 crc, unsigned char const *p, size_t
And here.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API -V2.
On Tue, Aug 05, 2008 at 08:39:44PM +0800, Herbert Xu wrote: > Hi Austin: > > On Tue, Aug 05, 2008 at 07:56:43AM -0400, Austin Zhang wrote: > > Revised by comments: > > Move hardware feature detect into module init; > > Revise dependency in Kconfig; > > Revise variable type; > > Add information output while module loading failed; > > > > > > >From NHM processor onward, Intel processors can support hardware > > accelerated > > CRC32c algorithm with the new CRC32 instruction in SSE 4.2 instruction > > set. > > The patch detects the availability of the feature, and chooses the most > > proper > > way to calculate CRC32c checksum. > > Byte code instructions are used for compiler compatibility. > > No MMX / XMM registers is involved in the implementation. > > > > Signed-off-by: Austin Zhang <[EMAIL PROTECTED]> > > Signed-off-by: Kent Liu <[EMAIL PROTECTED]> > > I tried to apply your patch but it doesn't work: > > $ git apply --check --whitespace=error-all ~/p > fatal: patch fragment without header at line 34: @@ -0,0 +1,190 @@ > $ > > Looks like your mail client has folded all the lines. >... Documentation/email-clients.txt contains a section explaining what to do in Evolution. > And here. > > Thanks, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API -V3.
Hi!
> ??Revised by comments:
> Add 'static' for limitation namespace;
> Resend for fixing lines-folded by adjusting evolution config;
> (The patch was created against 2.6.27-rc1)
>
> >From NHM processor onward, Intel processors can support hardware accelerated
> CRC32c algorithm with the new CRC32 instruction in SSE 4.2 instruction set.
> The patch detects the availability of the feature, and chooses the most proper
> way to calculate CRC32c checksum.
> Byte code instructions are used for compiler compatibility.
> No MMX / XMM registers is involved in the implementation.
>
> Signed-off-by: Austin Zhang <[EMAIL PROTECTED]>
> Signed-off-by: Kent Liu <[EMAIL PROTECTED]>
> ---
> arch/x86/crypto/Makefile |2
> arch/x86/crypto/crc32c-intel.c | 190
> +
> crypto/Kconfig | 12 ++
> include/asm-x86/cpufeature.h |2
> 4 files changed, 206 insertions(+)
>
> diff -Naurp linux-2.6/arch/x86/crypto/crc32c-intel.c
> linux-2.6-patch/arch/x86/crypto/crc32c-intel.c
> --- linux-2.6/arch/x86/crypto/crc32c-intel.c 1969-12-31 19:00:00.0
> -0500
> +++ linux-2.6-patch/arch/x86/crypto/crc32c-intel.c2008-08-05
> 21:57:37.0 -0400
> @@ -0,0 +1,190 @@
> +/*
> + * Using hardware provided CRC32 instruction to accelerate the CRC32
> disposal.
> + * CRC32C polynomial:0x1EDC6F41(BE)/0x82F63B78(LE)
> + * CRC32 is a new instruction in Intel SSE4.2, the reference can be found at:
> + * http://www.intel.com/products/processor/manuals/
> + * Intel(R) 64 and IA-32 Architectures Software Developer's Manual
> + * Volume 2A: Instruction Set Reference, A-M
Copyright / GPL?
> +#ifdef CONFIG_X86_64
> +#define REX_PRE "0x48, "
> +#define SCALE_F 8
> +#else
> +#define REX_PRE
> +#define SCALE_F 4
> +#endif
Ouch...
> +static u32 crc32c_intel_le_hw_byte(u32 crc, unsigned char const *data,
> size_t length)
> +{
> + while (length--) {
> + __asm__ __volatile__(
Are all the underscores neccessary?
> + ".byte 0xf2, 0xf, 0x38, 0xf0, 0xf1"
Ouch...
> +static int crc32c_intel_final(struct ahash_request *req)
> +{
> + u32 *crcp = ahash_request_ctx(req);
> +
> + *(__le32 *)req->result = ~cpu_to_le32p(crcp);
> + return 0;
This is not user visible, so le32 should be enough.
> +static int __init crc32c_intel_mod_init(void)
> +{
> + if (cpu_has_xmm4_2)
> + return crypto_register_alg(&alg);
> + else {
> + printk(KERN_ERR"No support in current hardware.\n");
Missing space.
> + return -1;
That's supposed to be errno, right?
> +config CRYPTO_CRC32C_INTEL
> +tristate "CRC32c INTEL hardware acceleration"
> + depends on X86
> +select CRYPTO_ALGAPI
> +help
> + In Intel processor with SSE4.2 supported, the processor will
> + support CRC32C implementation using hardware accelerated CRC32
> + instruction. This option will create 'crc32c-intel' module,
In Intel processor with SSE4.2, we can use hardware CRC32 acceleration.
> + which will enable any routine to use the CRC32 instruction to
> + gain performance compared with software implementation.
> + Module will be crc32c-intel.
crc32c-intel.ko?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API -V3.
On Wed, Aug 06, 2008 at 01:23:31AM -0400, Austin Zhang wrote:
> Revised by comments:
> Add 'static' for limitation namespace;
> Resend for fixing lines-folded by adjusting evolution config;
> (The patch was created against 2.6.27-rc1)
Applied to cryptodev-2.6. Thanks a lot Austin!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API -V3.
On Wed, Aug 06, 2008 at 11:42:26AM +0200, Pavel Machek wrote:
>
> > +static int crc32c_intel_final(struct ahash_request *req)
> > +{
> > + u32 *crcp = ahash_request_ctx(req);
> > +
> > + *(__le32 *)req->result = ~cpu_to_le32p(crcp);
> > + return 0;
>
> This is not user visible, so le32 should be enough.
Unfortunately I don't think le32 exists, it'd definitely be nice
to have it though.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API -V3.
Paval,
Thanks for your comments.
On Wed, 2008-08-06 at 11:42 +0200, Pavel Machek wrote:
> Copyright / GPL?
Yes, as : +MODULE_LICENSE("GPL");
> > +#ifdef CONFIG_X86_64
> > +#define REX_PRE "0x48, "
> > +#define SCALE_F 8
> > +#else
> > +#define REX_PRE
> > +#define SCALE_F 4
> > +#endif
>
> Ouch...
Any good suggestion will be appreciated.
> > +static u32 crc32c_intel_le_hw_byte(u32 crc, unsigned char const *data,
> > size_t length)
> > +{
> > + while (length--) {
> > + __asm__ __volatile__(
>
> Are all the underscores neccessary?
What's big impact if keep those underscores? Just keep ANSI C style.
>
> > + return -1;
>
> That's supposed to be errno, right?
Are you suggest "ENODEV"? It's a feature from the device but the device is
exact here.
And for the crc32c algorithm, there would be possible that several
algorithms registered themselves in crypto and user will don't care
which implementation will server him even the hardware accelerated
implementation don't exist in this processor.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API -V3.
On Wed, Aug 06, 2008 at 07:05:27AM -0400, Austin Zhang wrote:
>
> > > + return -1;
> >
> > That's supposed to be errno, right?
> Are you suggest "ENODEV"? It's a feature from the device but the device is
> exact here.
Yes I think this should be ENODEV to be consistent with the
existing drivers such as padlock-aes.c.
I'll make that change in cryptodev.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API -V3.
On Wed, 2008-08-06 at 19:17 +0800, Herbert Xu wrote: > On Wed, Aug 06, 2008 at 07:05:27AM -0400, Austin Zhang wrote: > > > > > > + return -1; > > > > > > That's supposed to be errno, right? > > Are you suggest "ENODEV"? It's a feature from the device but the device is > > exact here. > > Yes I think this should be ENODEV to be consistent with the > existing drivers such as padlock-aes.c. > > I'll make that change in cryptodev. > > Thanks, Thank you, Pavel and Herbert. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API -V3.
On Wed, Aug 06, 2008 at 07:17:24PM +0800, Herbert Xu wrote:
> On Wed, Aug 06, 2008 at 07:05:27AM -0400, Austin Zhang wrote:
> >
> > > > + return -1;
> > >
> > > That's supposed to be errno, right?
> > Are you suggest "ENODEV"? It's a feature from the device but the device is
> > exact here.
>
> Yes I think this should be ENODEV to be consistent with the
> existing drivers such as padlock-aes.c.
>
> I'll make that change in cryptodev.
In fact I'm going to kill that printk altogether since the fact
that this feature doesn't exist isn't an error.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API -V3.
On Wed 2008-08-06 07:05:27, Austin Zhang wrote:
> Paval,
>
> Thanks for your comments.
>
> On Wed, 2008-08-06 at 11:42 +0200, Pavel Machek wrote:
> > Copyright / GPL?
> Yes, as : ???+MODULE_LICENSE("GPL");
Well, it should normally go to comment at the beggining of file.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API -V3.
On Wed, Aug 06, 2008 at 02:14:52PM +0200, Pavel Machek wrote:
> On Wed 2008-08-06 07:05:27, Austin Zhang wrote:
> > Paval,
> >
> > Thanks for your comments.
> >
> > On Wed, 2008-08-06 at 11:42 +0200, Pavel Machek wrote:
> > > Copyright / GPL?
> > Yes, as : ???+MODULE_LICENSE("GPL");
>
> Well, it should normally go to comment at the beggining of file.
I've made the following change.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/arch/x86/crypto/crc32c-intel.c b/arch/x86/crypto/crc32c-intel.c
index 6cd20c5..c0e1e6b 100644
--- a/arch/x86/crypto/crc32c-intel.c
+++ b/arch/x86/crypto/crc32c-intel.c
@@ -5,6 +5,15 @@
* http://www.intel.com/products/processor/manuals/
* Intel(R) 64 and IA-32 Architectures Software Developer's Manual
* Volume 2A: Instruction Set Reference, A-M
+ *
+ * Copyright (c) 2008 Austin Zhang <[EMAIL PROTECTED]>
+ * Copyright (c) 2008 Kent Liu <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
*/
#include
#include
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API -V3.
On Tue, Aug 5, 2008 at 10:23 PM, Austin Zhang
<[EMAIL PROTECTED]> wrote:
> +#ifdef CONFIG_X86_64
> +#define REX_PRE "0x48, "
> +#define SCALE_F 8
> +#else
> +#define REX_PRE
> +#define SCALE_F 4
> +#endif
[...]
> +static u32 __pure crc32c_intel_le_hw(u32 crc, unsigned char const *p, size_t
> len)
> +{
> + unsigned int iquotient = len / SCALE_F;
> + unsigned int iremainder = len % SCALE_F;
> + unsigned long *ptmp = (unsigned long *)p;
> +
> + while (iquotient--) {
> + __asm__ __volatile__(
> + ".byte 0xf2, " REX_PRE "0xf, 0x38, 0xf1, 0xf1;"
> + :"=S"(crc)
> + :"0"(crc), "c"(*ptmp)
> + );
> + ptmp++;
I think you want to use
#define SCALE_F sizeof(unsigned long)
Since the loop iteration count etc depends on
ptmp++
which depends on the type being unsigned long.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API -V3.
Ulrich Drepper <[EMAIL PROTECTED]> wrote:
>
> I think you want to use
>
> #define SCALE_F sizeof(unsigned long)
Yeah in general that's what we should do. However, this driver
is specific to Intel x86 CPUs.
However if someone were to post a patch to do this I would happily
apply it.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API -V3.
On Fri 2008-08-08 21:35:30, Herbert Xu wrote: > Ulrich Drepper <[EMAIL PROTECTED]> wrote: > > > > I think you want to use > > > > #define SCALE_F sizeof(unsigned long) > > Yeah in general that's what we should do. However, this driver > is specific to Intel x86 CPUs. I thought we support intel x86 cpus in both 32 and 64bit modes...? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Using Intel CRC32 instruction to accelerate CRC32c algorithm by new crypto API -V3.
Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> I thought we support intel x86 cpus in both 32 and 64bit modes...?
Yes we do, but the original patch had ugly ifdefs that did the
same thing.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
