From: Andi Kleen <ak@suse.de>
To: linux-crypto@vger.kernel.org
Subject: {twofish,aes}-{x86_64,i586} versus C implementations
Date: Mon, 20 Aug 2007 02:34:25 +0200 [thread overview]
Message-ID: <200708200234.25620.ak@suse.de> (raw)
Hallo,
Currently there are two twofish and two aes implementions on x86.
Worse when both are enabled as modules a modprobe aes
will get the C version which seems to be slower on K8
and about the same speed on Core2 on my tests.
Is there a specific reason why anybody would prefer the C functions
over the assembler functions?
Possible reasons I could think of:
- If the assembler functions are optimized for a specific CPU the compiler
might be able to do a better job on other CPUs.
Is there evidence for this? I suspect it's not true.
- They are not trusted and might be buggy. I assume they have
been validated against the C versions with a wide range of input
data, correct?
If none of these reasons are valid it might make sense to disable
the C versions for x86 and only offer the assembler versions.
Then modprobe aes|twofish would DTRT automatically.
Comments?
-Andi
next reply other threads:[~2007-08-20 0:34 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-20 0:34 Andi Kleen [this message]
2007-08-20 1:01 ` {twofish,aes}-{x86_64,i586} versus C implementations Herbert Xu
2007-08-20 10:16 ` Andi Kleen
2007-08-20 9:45 ` Sebastian Siewior
2007-08-20 10:47 ` Andi Kleen
2007-08-20 10:08 ` Sebastian Siewior
2007-08-20 11:12 ` Andi Kleen
2007-08-20 11:27 ` Sebastian Siewior
2007-08-20 12:06 ` Herbert Xu
2007-08-20 13:06 ` Andi Kleen
2007-08-20 13:07 ` Herbert Xu
2007-09-02 22:42 ` Sebastian Siewior
2007-09-04 13:58 ` Andi Kleen
2007-09-19 12:29 ` Herbert Xu
2007-09-19 21:46 ` Sebastian Siewior
2007-09-20 0:20 ` Herbert Xu
2007-09-20 21:09 ` Sebastian Siewior
2007-09-30 12:23 ` Sebastian Siewior
2007-09-30 12:42 ` Sebastian Siewior
2007-10-03 7:35 ` Herbert Xu
2007-10-04 8:35 ` Sebastian Siewior
2007-10-03 19:23 ` [PATCH] [crypto] load the DES module by an alias Sebastian Siewior
2007-10-05 8:48 ` Herbert Xu
2007-10-04 7:37 ` [PATCH] [crypto] load the AES " Sebastian Siewior
2007-10-05 8:52 ` Herbert Xu
2007-10-04 7:37 ` [PATCH] [crypto] load the SHA1[1|256] " Sebastian Siewior
2007-10-05 8:57 ` Herbert Xu
2007-10-05 13:50 ` Sebastian Siewior
2007-10-05 13:12 ` [PATCH] [crypto] load the SHA1[1|256] module by an alias (v2) Sebastian Siewior
2007-10-05 15:10 ` Herbert Xu
2007-10-06 22:02 ` Sebastian Siewior
2007-10-08 3:21 ` Herbert Xu
2007-10-07 21:42 ` Sebastian Siewior
2007-10-08 3:20 ` Herbert Xu
2007-10-08 12:35 ` Sebastian Siewior
2007-10-08 4:12 ` Herbert Xu
2007-10-05 14:20 ` [PATCH] [crypto] load the SHA1[1|256] module by an alias Herbert Xu
2007-10-06 21:54 ` Sebastian Siewior
2007-10-08 11:25 ` Jan Glauber
2007-10-08 11:30 ` Sebastian Siewior
2007-10-04 8:48 ` {twofish,aes}-{x86_64,i586} versus C implementations Herbert Xu
2007-10-04 9:31 ` Andi Kleen
2007-10-04 10:00 ` Sebastian Siewior
2007-10-04 10:00 ` Herbert Xu
2007-10-04 9:39 ` Sebastian Siewior
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=200708200234.25620.ak@suse.de \
--to=ak@suse.de \
--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 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.