> 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
