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
Attachment:
signature.asc
Description: This is a digitally signed message part
