From: "Huang, Ying" <ying.huang@intel.com>
To: Sebastian Siewior <linux-crypto@ml.breakpoint.cc>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
"Adam J. Richter" <adam@yggdrasil.com>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, mingo@elte.hu, tglx@linutronix.de
Subject: Re: [PATCH -mm crypto] AES: x86_64 asm implementation optimization
Date: Thu, 17 Apr 2008 09:52:03 +0800 [thread overview]
Message-ID: <1208397123.4322.21.camel@caritas-dev.intel.com> (raw)
In-Reply-To: <20080416184016.GA21365@Chamillionaire.breakpoint.cc>
On Wed, 2008-04-16 at 20:40 +0200, Sebastian Siewior wrote:
[...]
> >> >--- a/include/crypto/aes.h
> >> >+++ b/include/crypto/aes.h
> >> >@@ -19,6 +19,7 @@
> >> >
> >> > struct crypto_aes_ctx {
> >> > u32 key_length;
> >> >+ u32 _pad1;
> >>
> >> Why is this pad required? Do you want special alignment of the keys?
> >
> >Because the key is loaded in 64bit in this patch, I want to align the
> >key with 64bit address.
>
> Than this won't work all the time. To make it bulletproof
> - set .cra_alignmask in the glue code properly
> - use the attribute aligned thing
> - retrieve your private struct via crypto_tfm_ctx_aligned()
As far as I know, the CRYPTO_MINALIGN is defined in
include/linux/crypto.h as __alignof__(unsigned long long), and the
__crt_ctx in crypto_tfm is aligned in CRYPTO_MINALIGN. So I think adding
a pad is sufficient for x86_64 implementation.
Best Regards,
Huang Ying
next prev parent reply other threads:[~2008-04-17 1:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-09 6:41 [PATCH -mm crypto] AES: x86_64 asm implementation optimization Huang, Ying
2008-04-09 6:41 ` Huang, Ying
2008-04-16 7:31 ` Sebastian Siewior
2008-04-16 8:19 ` Huang, Ying
2008-04-16 8:23 ` Andi Kleen
2008-04-16 9:50 ` Herbert Xu
2008-04-16 18:40 ` Sebastian Siewior
2008-04-17 1:52 ` Huang, Ying [this message]
2008-04-17 3:34 ` Herbert Xu
2008-04-17 4:53 ` Huang, Ying
2008-04-23 22:28 ` Sebastian Siewior
2008-04-24 0:51 ` Herbert Xu
2008-04-17 3:36 ` Huang, Ying
2008-04-23 22:32 ` Sebastian Siewior
2008-04-25 3:11 ` Huang, Ying
2008-04-25 7:12 ` Sebastian Siewior
2008-04-25 7:21 ` Huang, Ying
2008-04-25 7:37 ` Sebastian Siewior
2008-04-29 22:12 ` Sebastian Siewior
2008-05-04 6:25 ` dean gaudet
2008-05-07 5:12 ` Huang, Ying
2008-05-07 5:26 ` Huang, Ying
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=1208397123.4322.21.camel@caritas-dev.intel.com \
--to=ying.huang@intel.com \
--cc=adam@yggdrasil.com \
--cc=akpm@linux-foundation.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@ml.breakpoint.cc \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.