On Fri, 2008-12-12 at 12:24 +0800, Geoff Thorpe wrote: > On Thursday 11 December 2008 23:02:12 Huang Ying wrote: > > On Fri, 2008-12-12 at 11:38 +0800, Geoff Thorpe wrote: > > > 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. > > OK, I (mis)understood from your original mail that you could only > accelerate a subset of modes. If you can accelerate them all, then > please do so by implementing an intel/aes-ni engine. But not by > branching in the vanilla implementation. > > > 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. > > And my suggestion is: > > - write an engine for your hardware.
OK. I will write an engine version firstly, at least for discussion. Best Regards, Huang Ying
signature.asc
Description: This is a digitally signed message part
