From: Stefan Hellermann <stefan@the2masters.de>
To: Sebastian Siewior <linux-crypto@ml.breakpoint.cc>
Cc: linux-crypto@vger.kernel.org
Subject: Re: [RFC] [crypto] padlock-aes loadkey ondemand
Date: Sun, 30 Mar 2008 21:03:18 +0200 [thread overview]
Message-ID: <47EFE3F6.4060704@the2masters.de> (raw)
In-Reply-To: <20080328223333.GB24018@Chamillionaire.breakpoint.cc>
Sebastian Siewior schrieb:
> Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc>
> ---
> Stefan, if you have some spare time could you please look if this patch
> improves padlock + xts performance somehow?
Hi,
I tested this patch with success, "512 bit key, 8192 byte blocks" is 29% faster!
Thanks for this work!
Tested-By: Stefan Hellermann
(Or what is the appropriate line here?)
Here's tcrypt mode=200 output for xts without this patch
testing speed of xts(aes) decryption
test 0 (256 bit key, 16 byte blocks): 1 operation in 947 cycles (16 bytes)
test 1 (256 bit key, 64 byte blocks): 1 operation in 1645 cycles (64 bytes)
test 2 (256 bit key, 256 byte blocks): 1 operation in 4393 cycles (256 bytes)
test 3 (256 bit key, 1024 byte blocks): 1 operation in 15385 cycles (1024 bytes)
test 4 (256 bit key, 8192 byte blocks): 1 operation in 118990 cycles (8192 bytes)
test 5 (384 bit key, 16 byte blocks): 1 operation in 962 cycles (16 bytes)
test 6 (384 bit key, 64 byte blocks): 1 operation in 1688 cycles (64 bytes)
test 7 (384 bit key, 256 byte blocks): 1 operation in 4532 cycles (256 bytes)
test 8 (384 bit key, 1024 byte blocks): 1 operation in 15908 cycles (1024 bytes)
test 9 (384 bit key, 8192 byte blocks): 1 operation in 123097 cycles (8192 bytes)
test 10 (512 bit key, 16 byte blocks): 1 operation in 974 cycles (16 bytes)
test 11 (512 bit key, 64 byte blocks): 1 operation in 1710 cycles (64 bytes)
test 12 (512 bit key, 256 byte blocks): 1 operation in 4664 cycles (256 bytes)
test 13 (512 bit key, 1024 byte blocks): 1 operation in 16424 cycles (1024 bytes)
test 14 (512 bit key, 8192 byte blocks): 1 operation in 127197 cycles (8192 bytes)
and here's the output with this patch:
testing speed of xts(aes) decryption
test 0 (256 bit key, 16 byte blocks): 1 operation in 952 cycles (16 bytes)
test 1 (256 bit key, 64 byte blocks): 1 operation in 1462 cycles (64 bytes)
test 2 (256 bit key, 256 byte blocks): 1 operation in 3454 cycles (256 bytes)
test 3 (256 bit key, 1024 byte blocks): 1 operation in 11422 cycles (1024 bytes)
test 4 (256 bit key, 8192 byte blocks): 1 operation in 86779 cycles (8192 bytes)
test 5 (384 bit key, 16 byte blocks): 1 operation in 967 cycles (16 bytes)
test 6 (384 bit key, 64 byte blocks): 1 operation in 1467 cycles (64 bytes)
test 7 (384 bit key, 256 byte blocks): 1 operation in 3473 cycles (256 bytes)
test 8 (384 bit key, 1024 byte blocks): 1 operation in 11441 cycles (1024 bytes)
test 9 (384 bit key, 8192 byte blocks): 1 operation in 86798 cycles (8192 bytes)
test 10 (512 bit key, 16 byte blocks): 1 operation in 979 cycles (16 bytes)
test 11 (512 bit key, 64 byte blocks): 1 operation in 1503 cycles (64 bytes)
test 12 (512 bit key, 256 byte blocks): 1 operation in 3605 cycles (256 bytes)
test 13 (512 bit key, 1024 byte blocks): 1 operation in 11957 cycles (1024 bytes)
test 14 (512 bit key, 8192 byte blocks): 1 operation in 90898 cycles (8192 bytes)
But it's far away from aes(cbc)
test 14 (256 bit key, 8192 byte blocks): 1 operation in 8912 cycles (8192 bytes)
... cbc is now only 10 times faster, not 14 times :)
Stefan
>
> drivers/crypto/padlock-aes.c | 35 +++++++++++++++++++++++++++++------
> 1 files changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
> index bb30eb9..1ebbe8c 100644
> --- a/drivers/crypto/padlock-aes.c
> +++ b/drivers/crypto/padlock-aes.c
> @@ -48,6 +48,8 @@ struct aes_ctx {
> u32 *D;
> };
>
> +static struct aes_ctx *last_key;
> +
> /* Tells whether the ACE is capable to generate
> the extended key for a given key_len. */
> static inline int
> @@ -115,6 +117,7 @@ static int aes_set_key(struct crypto_tfm *tfm, const u8 *in_key,
> ctx->cword.encrypt.ksize = (key_len - 16) / 8;
> ctx->cword.decrypt.ksize = ctx->cword.encrypt.ksize;
>
> + last_key = ctx;
> /* Don't generate extended keys if the hardware can do it. */
> if (aes_hw_extkey_available(key_len))
> return 0;
> @@ -205,14 +208,22 @@ static inline u8 *padlock_xcrypt_cbc(const u8 *input, u8 *output, void *key,
> static void aes_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
> {
> struct aes_ctx *ctx = aes_ctx(tfm);
> - padlock_reset_key();
> +
> + if (last_key != ctx) {
> + last_key = ctx;
> + padlock_reset_key();
> + }
> aes_crypt(in, out, ctx->E, &ctx->cword.encrypt);
> }
>
> static void aes_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
> {
> struct aes_ctx *ctx = aes_ctx(tfm);
> - padlock_reset_key();
> +
> + if (last_key != ctx) {
> + last_key = ctx;
> + padlock_reset_key();
> + }
> aes_crypt(in, out, ctx->D, &ctx->cword.decrypt);
> }
>
> @@ -245,7 +256,10 @@ static int ecb_aes_encrypt(struct blkcipher_desc *desc,
> struct blkcipher_walk walk;
> int err;
>
> - padlock_reset_key();
> + if (last_key != ctx) {
> + last_key = ctx;
> + padlock_reset_key();
> + }
>
> blkcipher_walk_init(&walk, dst, src, nbytes);
> err = blkcipher_walk_virt(desc, &walk);
> @@ -269,7 +283,10 @@ static int ecb_aes_decrypt(struct blkcipher_desc *desc,
> struct blkcipher_walk walk;
> int err;
>
> - padlock_reset_key();
> + if (last_key != ctx) {
> + last_key = ctx;
> + padlock_reset_key();
> + }
>
> blkcipher_walk_init(&walk, dst, src, nbytes);
> err = blkcipher_walk_virt(desc, &walk);
> @@ -315,7 +332,10 @@ static int cbc_aes_encrypt(struct blkcipher_desc *desc,
> struct blkcipher_walk walk;
> int err;
>
> - padlock_reset_key();
> + if (last_key != ctx) {
> + last_key = ctx;
> + padlock_reset_key();
> + }
>
> blkcipher_walk_init(&walk, dst, src, nbytes);
> err = blkcipher_walk_virt(desc, &walk);
> @@ -341,7 +361,10 @@ static int cbc_aes_decrypt(struct blkcipher_desc *desc,
> struct blkcipher_walk walk;
> int err;
>
> - padlock_reset_key();
> + if (last_key != ctx) {
> + last_key = ctx;
> + padlock_reset_key();
> + }
>
> blkcipher_walk_init(&walk, dst, src, nbytes);
> err = blkcipher_walk_virt(desc, &walk);
next prev parent reply other threads:[~2008-03-30 19:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-28 22:33 [RFC] [crypto] padlock-aes loadkey ondemand Sebastian Siewior
2008-03-30 19:03 ` Stefan Hellermann [this message]
2008-03-30 21:01 ` Sebastian Siewior
2008-04-01 18:38 ` Stefan Hellermann
2008-04-02 6:44 ` Sebastian Siewior
2008-04-02 6:50 ` Herbert Xu
2008-04-02 7:17 ` Sebastian Siewior
2008-04-02 7:22 ` Herbert Xu
2008-08-07 14:53 ` Herbert Xu
2008-08-09 11:20 ` Sebastian Siewior
2008-08-31 6:01 ` Herbert Xu
2008-04-02 15:48 ` Stefan Hellermann
2008-04-09 16:38 ` Herbert Xu
2008-04-02 6:03 ` Herbert Xu
2008-04-02 6:26 ` Sebastian Siewior
2008-04-02 6:31 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47EFE3F6.4060704@the2masters.de \
--to=stefan@the2masters.de \
--cc=linux-crypto@ml.breakpoint.cc \
--cc=linux-crypto@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox