All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: Bob Deblier <bob.deblier@telenet.be>
Cc: linux-kernel@vger.kernel.org
Subject: Re: AES assembler optimizations
Date: 9 Aug 2004 20:16:22 +0200
Date: Mon, 9 Aug 2004 20:16:22 +0200	[thread overview]
Message-ID: <20040809181622.GA42722@muc.de> (raw)
In-Reply-To: <1092067328.4332.40.camel@orion>

On Mon, Aug 09, 2004 at 06:02:08PM +0200, Bob Deblier wrote:
> On Mon, 2004-08-09 at 16:28, Andi Kleen wrote:
> > Bob Deblier <bob.deblier@telenet.be> writes:
> > 
> > > Just picked up on KernelTrap that there were some problems with
> > > optimized AES code; if you wish, I can provide my own LGPL licensed (or
> > > I can relicense them for you under GPL), as included in the BeeCrypt
> > > Cryptography Library.
> > >
> > > I have generic i586 code and SSE-optimized code available in GNU
> > > assembler format. Latest version is always available on SourceForge
> > > (http://sourceforge.net/cvs/?group_id=8924).
> > 
> > Would be interesting.  Do you have any benchmarks for your code?
> 
> BeeCrypt contains benchmarks in the 'tests' subdirectory. Running of
> 'make bench' will execute them. Benchmarks results below for repeatedly
> looping over the same 16K block, produced by 'benchbc', without any
> tweaks (YMMV):

I guess a cache cold benchmark would be more interesting. AFAIK 
linux does encryption/decryption usually on cache cold buffers.

> P4 2400, with MMX:
> ECB encrypted 738304 KB in 10.00 seconds = 73823.02 KB/s
> CBC encrypted 659456 KB in 10.00 seconds = 65925.82 KB/s
> ECB decrypted 765952 KB in 10.00 seconds = 76564.57 KB/s
> CBC decrypted 616448 KB in 10.02 seconds = 61546.33 KB/s
> 
> P4 2400, plain i386:
> ECB encrypted 584704 KB in 10.01 seconds = 58435.34 KB/s
> CBC encrypted 570368 KB in 10.01 seconds = 56979.82 KB/s
> ECB decrypted 444416 KB in 10.02 seconds = 44357.32 KB/s
> CBC decrypted 423936 KB in 10.02 seconds = 42304.76 KB/s

MMX seems to be fast enough that it's probably a win to use,
even with the overhead of kernel_fpu_begin/end

It usually annoys the "low latency" people a bit though because
it requires disabling kernel preemption during the computation.

-Andi

  parent reply	other threads:[~2004-08-09 18:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2riR3-7U5-3@gated-at.bofh.it>
2004-08-09 14:28 ` AES assembler optimizations Andi Kleen
2004-08-09 16:02   ` Bob Deblier
2004-08-09 17:12     ` Matti Aarnio
2004-08-10 19:51       ` H. Peter Anvin
2004-08-10 20:36         ` David S. Miller
2004-08-11  1:02           ` Paul Mackerras
2004-08-11  1:25             ` David S. Miller
2004-08-12 20:18           ` Bill Davidsen
2004-08-09 18:16     ` Andi Kleen [this message]
2004-08-09 20:20     ` dean gaudet
2004-08-09 13:47 Bob Deblier
2004-08-09 14:32 ` Patrick McFarland

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=20040809181622.GA42722@muc.de \
    --to=ak@muc.de \
    --cc=bob.deblier@telenet.be \
    --cc=linux-kernel@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.