Re: [RFC PATCH crypto] AES: Add support to Intel AES-NI instructions

[Herbert Xu]

On Wed, Dec 17, 2008 at 11:33:39AM +0800, Huang Ying wrote:
> 
> - 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.

Yes that's pretty much what I'd like to see.

Ideally we should implement all the commonly used modes of
oeprations so that the simple AES cipher itself is never used
except on small chunks of data.  However, for now I think doing
just cbc should be sufficient since that's the most common use
case.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/