Messages in this thread | | | Subject | Re: [RFC PATCH crypto 4/4] AES-NI: Add support to Intel AES-NI instructions for x86_64 platform | From | Huang Ying <> | Date | Fri, 09 Jan 2009 16:54:33 +0800 |
| |
On Fri, 2009-01-09 at 15:01 +0800, Herbert Xu wrote: > > - ablkcipher asynchronous machanism is used to delay a crypto request > > to work queue context upon FPU state is using by other kernel > > context. > > Actually I was thinking of something as simple as just using > cryptd as is. That is, register a blkcipher algorithm for your > version of cbc-aes, but don't register under the name cbc(aes), > e.g., register it under the name of __cbc-aes-aesni for both alg > name and driver name. You can register it under cbc(aes) too > if you add the fallback in there. > > Then for the real thing, just allocate the blkcipher __cbc_*, > plus the ablkcipher cryptd(__cbc_*), and invoke the right one > depending on caller context.
I have ever considered this method too. This one is simpler, but the drawbacks are as follow:
- cryptd thread is not per-CPU, so I think there will be some unnecessary cache inter-CPU migration. Why not use a dedicate workqueue or just system events workqueue?
- with cryptd(__*-aes-aesni), we need 4 internal tfms for each external tfm allocation request. For example, for one external cbc(aes) tfm allocation request, we need one cbc(aes) ablkcipher tfm, one cryptd(cbc-aes-aesni) tfm, and two cbc-aes-aesni tfm. Do we use too much memory? And we need to call aesni_set_key() twice.
> This is even simpler for the modes which you don't implement. > In that case you would just allocate FOO(aes-aesni) in conjunction > with cryptd(FOO(aes-aesni)).
Yes. This is really a simple method.
Best Regards, Huang Ying
[unhandled content-type:application/pgp-signature] | |