Prev: add x86 platform driver tree
Next: firewire: core: check for 1394a compliant IRM, fix inaccessibility of Sony camcorder
From: Milan Broz on 31 May 2010 15:00
On 05/31/2010 08:27 PM, Andi Kleen wrote:

>>> AES-NI is not asynchronous and doesn't have limited resources.
>>
>> AES-NI used asynchronous crypto interface, was using asynchronous
>> crypto API cryptd daemon IIRC. So this changed?
>
> AFAIK all ciphers use the asynchronous interface, but that
> doesn't mean they are actually asynchronous. AES-NI certainly
> does not require running in a special thread. The only
> thing it doesn't support is running from interrupt context.

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.

So I am mistaken here?

Milan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 31 May 2010 15:10
> 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.

Each CPU core has its own support for AES-NI (it's part
of the SSE units), there's no shared crypto hardware between cores.

There are other systems with separate AES units, but they are
considerably more obscure.

-Andi
--
ak(a)linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Herbert Xu on 31 May 2010 18:10
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(a)gondor.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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: huang ying on 31 May 2010 21:50
On Tue, Jun 1, 2010 at 6:07 AM, Herbert Xu <herbert(a)gondor.apana.org.au> wrote:
> 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.

The reason for aes-ni to use async interface is that the FPU/SSE
instructions enclosed by kernel_fpu_begin and kernel_fpu_end is not
reentranceable. That is, it is not safe to use FPU/SSE instructions in
interrupt context, if the instructions are used in interrupted
context. So irq_fpu_usable is used in the async interface of aes-ni,
and go asynchronous implementation only if !irq_fpu_usable. In most
instances, the async interface of aes-ni will run in synchronous mode.

Best Regards,
Huang Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mikulas Patocka on 31 May 2010 22:50
> > >> 2) Per volume threads and mempools were added to solve low memory
> > >> problems (exhausted mempools), isn't now possible deadlock here again?
> > >
> > > Increasing the number of parallel submitters does not increase deadlocks
> > > with mempool as long as they don't nest. They would just
> > > block each other, but eventually make progress as one finishes.
> >
> > I mean if they nest of course, sorry for confusion.
>
> No change to that, it's the same as it always worked.
>
> Anyways, Right now you would need to nest more than 16 times I think
> to exhaust the mempool (or 8, but the pages are less critical I think)
>
> For me that seems like a "don't do that if hurts" situation.

If the mempools are per-instance (they are), it can nest any number of
times, because each nested instance will get new mempools. It is not a
problem.

Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: add x86 platform driver tree
Next: firewire: core: check for 1394a compliant IRM, fix inaccessibility of Sony camcorder