[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100531220700.GA23076@gondor.apana.org.au>
Date: Tue, 1 Jun 2010 08:07:00 +1000
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Andi Kleen <andi@...stfloor.org>
Cc: Milan Broz <mbroz@...hat.com>,
device-mapper development <dm-devel@...hat.com>,
linux-kernel@...r.kernel.org, agk@...hat.com, ak@...ux.intel.com
Subject: Re: [dm-devel] [PATCH] DM-CRYPT: Scale to multiple CPUs
On Mon, May 31, 2010 at 09:04:00PM +0200, Andi Kleen wrote:
> > I mean how it is implemented now in crypto API, and I was almost
> > sure that aes-ni acceleration code uses cryptd (iow real asynchronous processing)
> > and also that not all CPU cores can run these instruction in parallel.
>
> I think you can configure it to use cryptd (or pcrypt), but it's not default
> and usually higher overhead.
Right. The only reason aes-ni uses the async interface is to
work around the fact that you have to save FPU state when using
it. For dm-crypt you can consider it to be synchronous.
Note that cryptd is nothing like pcrypt. cryptd always keeps
the work on the local CPU, even if goes into another thread.
OTOH pcrypt was designed to parallelise the work across CPUs.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists