On Wed, 2008-12-17 at 09:26 +0800, Herbert Xu wrote: > Huang Ying <ying.huang@xxxxxxxxx> wrote: > > > > f. if TS is clear, then use x86_64 implementation. Otherwise if > > user-space has touched the FPU, we save the state, if not then simply > > clear TS. > > Well I'd rather avoid using the x86_64 implementation ever because > unless the chip guys have really screwed up we should be looking at > a difference of at least a factor of 10. > > BTW I wasn't very clear in the original email. You'd only do the > asynchronous operation for CBC/ECB. For the simple AES case I > suppose we'll just have to stick to the x86_64 fallback. This'll > really suck for disk encryption but I guess you could always add > an LRW/XTS mode to your code. It seems that asynchronous operations are only provided in blkcipher level not cipher level. So the situation may be as follow: - Now an AES core block algorithm is implemented with AES-NI as CRYPTO_ALG_TYPE_CIPHER, which can benefit all modes (CBC, LRW, etc). But because it seems that there is no asynchronous interface for CRYPTO_ALG_TYPE_CIPHER, the AES core block algorithm can not use a thread to defer real operations. - To take full advantage of AES-NI pipeline implementation, at least "cbc(aes)", "ecb(aes)" and "ctr(aes)" should be implemented as CRYPTO_ALG_TYPE_ABLKCIPHER. So a thread can be used to defer real operation upon soft_irq. Because the combination that kernel process context FPU usage + soft_irq AES usage is fairly rare, I think the above combination is acceptable. That is, - In AES core block algorithm implementation with AES-NI, use x86_64 implementation for the combination above. - In "cbc(aes)", "ecb(aes)" and "ctr(aes)", use thread deferring for the combination above. Best Regards, Huang Ying
Attachment:
signature.asc
Description: This is a digitally signed message part
