On Sun, Mar 18, 2012 at 07:16:27PM +0100, Andy Polyakov wrote: > Hi, > > > 1.0.1: > > $ openssl speed aes-128-cbc: > > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > > bytes > > aes-128 cbc 110450.10k 120831.36k 122216.11k 123465.05k > > 123909.46k > > > > $ openssl speed -evp aes-128-cbc: > > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > > bytes > > aes-128-cbc 669703.39k 709092.05k 721489.25k 714057.39k > > 724320.26k > > > > So if you directly use the AES API you used to have a little better > > performance, > > but now you don't get the AES-NI support and so are a factor slower when > > using it. > > ??? AES-NI was *never* available through "AES API", always through EVP, > either through ["3rd party"] engine or starting with 1.0.1 integrated > directly at EVP level. Well, it is possible to slightly modify AES-NI > assembler and compile it as drop-in *replacement* for vanilla AES > module, but it was never "offered" as supported option nor "advertised". > Somebody might have done it, but in such case it's something to settle > between you and that vendor. It should be noted that such drop-in won't > provide adequate performance for parallelizable modes other than CBC > decrypt. > > Or did I misunderstand the question?
I guess my question is basicly why the selection between the different assembler implementations happens at the EVP level and not some lower level. I was expecting the lower level to also use AES NI when it was available. Kurt ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
