> This builds on top of the 7 patch series I sent the other day which > laid the foundation for sparc crypto opcode support. > > The first patch plugs in optimized versions of key expansion and > AES_{decrypt,encrypt}() > > The second patch is modelled on the AESNI support and explicitly > optimizes ECB, CBC, CTR, OFB, and CFB modes. I'll do the remaining > modes soon.
I feel that we need to take a step back and reiterate. Preprocessor isn't mighty enough on Solaris and we have to come up with alternative solution. I can (and willing to:-) make a suggestion, but maybe not as soon as you [or somebody else] might anticipate... Meanwhile some side notes. What is rationale behind choosing interleave factor of two for parallelizable modes? Judging from aes-128 cbc encrypt benchmarks AES round instruction latency is 4. If processor can pair together two half-round instructions (I refer to fact that it takes two instructions to perform single round), then optimal interleave factor should be 4. Do you have performance metrics, specifically throughput, for instructions in question? Did you attempt higher interleave factor? Is ECB a "must have"? Are there critical applications? I mean it's probably lesser point to implement as much modes as possible... Speaking of modes. I haven't examined the DES and Camellia submission, but I'm going to push for sharing mode code between all submissions... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org