Am Mittwoch, 8. Juni 2016, 17:03:54 schrieb Herbert Xu:
Hi Herbert,
> On Wed, Jun 08, 2016 at 10:58:37AM +0200, Stephan Mueller wrote:
> > Indeed, I used ctr(aes-aesni) instead of ctr-aes-aesni according to the
> > refcnt in /proc/crypto. The reason was that I used the sync skcipher API
> > which naturally excludes the ctr-aes-aesni.
> >
> > When changing it to really use ctr-aes-aesni, I get: between 450%
> > performance gains (for 4096 bytes -- 780 MB/s(!)) and 4% gain (for 16
> > bytes).
> >
> > Though, on 32 bit with ctr(aes-aesni) -- which is a blkcipher -- I get a
> > performance degradation of 10% (4096 bytes) and 20% (16 bytes).
> >
> > Any ideas on how to handle the blkcipher in a better way?
>
> You should always use ctr-aes-aesni, ctr(aes-aesni) makes no sense.
>
> So I don't quite understand why you need to handle blkcipher, does
> ctr-aes-aesni not work on 32-bit?
No, it does not:
#ifdef CONFIG_X86_64
}, {
.cra_name = "__ctr-aes-aesni",
.cra_driver_name = "__driver-ctr-aes-aesni",
...
}, {
.cra_name = "ctr(aes)",
.cra_driver_name = "ctr-aes-aesni",
==> ctr-aes-aesni is not available in 32 bit. Only aes-aesni is available in
32 bit so the system defaults to ctr(aes-aesni).
Note, in my tests I use a generic code that requests ctr(aes). I am not arch-
specific in the code. The discussion above is the analysis of the kernel
crypto API's decisions.
Ciao
Stephan
--
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
