On Fri, 2008-12-12 at 11:38 +0800, Geoff Thorpe wrote: > On Thursday 11 December 2008 20:39:41 Huang Ying wrote: > > On Thu, 2008-12-11 at 23:03 +0800, Geoff Thorpe wrote: > > > Engines like eng_cryptodev.c *are* built in (they're in > > > ./crypto/engine/ rather ./engines/) and the intention is that they > > > should be the implementation "de base" for those build targets to > > > which they apply. Cryptodev is the only one so far, but there could > > > be others. In fact, the padlock support for VIA chips (which is > > > comparable to what's being discussed here, with all due respect to > > > the intel instruction-set faithful) sits in ./engines like any other > > > h/w support - a similar argument could be made that, on chips that > > > support it, it should provide the default implementation(s), but > > > right now they've been happy enough to make it a non-default option. > > > > The difference between Intel AES-NI and padlock is that padlock > > provide support for different modes directly including ecb, cbc, cfb > > and ofb, while Intel AES-NI just provides instructions for AES core > > block algorithm NOT for modes directly. At the same time, AES-NI > > pipelining implementation can benefit ecb encrypt and cbc decrypt and > > counter mode. > > > > If we implement AES-NI with "branch", we can get full power of AES-NI > > except ecb and ctr mode. > > > > If we implement AES-NI with "engine", we can get full power of AES-NI > > for all modes. But we must duplicate mode implementations that can not > > benefit from AES-NI, such as cfb, ofb, etc. > > > > Do you OK with code duplication? > > The cipher and digest support is at the granularity of "nid"s, and these > combine algorithm, key-length, and mode. So if you implement support for > those cipher,length,mode combinations that can be accelerated by AES-NI, > your engine will only be invoked for those combinations. You're not > obliged to implement anything else, and indeed there is nothing to be > gained by doing so.
The situation is: - We implement cbc and ecb mode in engine - If we implement cfb and ofb in engine too, we will duplicate code of cfb and ofb mode itself. - If we do not implement cfb and ofb in engine, no code duplication, BUT we can NOT get AES-NI acceleration for AES core block algorithm (which benefit cfb and ofb too) until we have a "branch" version. So my suggestion is: - Accelerate AES core block algorithm with "branch" version. Which is used by cbc, cfb and ofb too. - Accelerate AES ecb and ctr? with "engine" version. Best Regards, Huang Ying
signature.asc
Description: This is a digitally signed message part
