Hello,
On Wed, 27 Oct 2021 at 22:17, Shawn Heisey <[email protected]> wrote: > > I am building haproxy from source. > > For some load balancers that I used to manage, I also built openssl from > source, statically linked, and compiled haproxy against that, because > the openssl included with the OS (CentOS 6 if I recall correctly) was > ANCIENT. I don't know how to get haproxy to use the alternate openssl > at runtime, which is why I compiled openssl to be linked statically. > > For my own servers, I am running Ubuntu 20, which has a reasonably > current openssl version already included. > > I know that openssl on Ubuntu is compiled with support for Intel's > AES-NI instructions for accelerating crypto. That can be seen by > running these two commands on a system with a proper CPU and comparing > the reported speeds: > > openssl speed -elapsed aes-128-cbc > openssl speed -elapsed -evp aes-128-cbc > > But the fact that it requires the -evp arg on the commandline to get the > acceleration makes me wonder if maybe openssl 1.1.1 has CPU acceleration > turned off by default, requiring an explicit enable to use it. You are not comparing aes-ni on vs aes-ni off, you are comparing two very different crypto interfaces, one supports aes-ni the other doesn't, but there is also a big difference in the interface speed itself. The proper comparison is: # aes-ni as per cpu flags: openssl speed -elapsed -evp aes-128-cbc # aes-ni cpu flag hidden: OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp aes-128-cbc I'd be surprised if the OpenSSL API calls we are using doesn't support AES-NI. Lukas
