Re: Does haproxy utlize openssl with AES-NI if present?

[Shawn Heisey]

On 10/29/21 3:58 AM, Emerson Gomes wrote:
If you want "definitive proof" that you're not using AES-NI 
instructions during your benchmark, you could simply compile OpenSSL 
(and then HAproxy, linking it to this OpenSSL version) passing 
"-noaes" flag to GCC in the process.



I know from other tests that the installed openssl package is CAPABLE of 
using the aes-ni instructions.


What I am trying to determine is whether or not haproxy is using them.  
Lukas is probably right that there is no problem here, and that this 
whole endeavor is a waste of time.


On 10/29/21 1:15 AM, Willy Tarreau wrote:


By the way on this subject, based on the numbers you reported for
openssl speed, the speed differences on as low bandwidth a network as
1 Gbps are not even relevant. Your machine can encrypt/decrypt at
roughly 2 Gbps per core even when not using AES-NI, so in this case
it's more important to watch the CPU utilization during the transfer
than the transfer speed itself, which can be affected by many other
factors.



Interesting that the curl transfer speed was only 62 MB/second in my 
test, rather than the 100 MB/s or more that I would expect if haproxy 
and apache were saturating the gigabit connection. The backends are all 
cleartext on localhost, not ssl.


The server has two of these CPUs:

model name  : Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz

I repeated the curl test, and this time there was no big difference in 
transfer speeds.  One got 63 MB/s, the other got 62 MB/s.  I tried to 
look for CPU differences with "top" on a 0.2 second delay, but even with 
the flags to disable acceleration, haproxy CPU usage during the curl 
transfer was 0.0 percent, so that tool is useless.  I don't know how to 
use any real profiling tools.


It was suggested that I do the data transfer from another machine, which 
is what I did.  Just for thoroughness, I did the test again on the same 
machine as haproxy, and this time (without that pesky gigabit network in 
the way) I did see a very significant difference in transfer speed.  
Internal DNS resolves the hostname I used to the machine's private IP 
address.


root@smeagol:~# curl --ciphers ECDHE-RSA-AES256-GCM-SHA384 
https://www.DOMAIN.com/4gbrandom > /dev/null
  % Total    % Received % Xferd  Average Speed   Time Time Time  
Current

 Dload  Upload   Total Spent    Left  Speed
100 4096M  100 4096M    0 0   192M  0  0:00:21  0:00:21 
--:--:--  201M
root@smeagol:~# curl --ciphers ECDHE-RSA-AES256-GCM-SHA384 
https://www.DOMAIN.com/4gbrandom > /dev/null
  % Total    % Received % Xferd  Average Speed   Time Time Time  
Current

 Dload  Upload   Total Spent    Left  Speed
100 4096M  100 4096M    0 0  67.6M  0  0:01:00  0:01:00 --:--:-- 
70.0M


I am going to conclude from this that acceleration is working. If 
somebody wants to point me at a crash course in how to use profiling 
tools, I will give that a try.


Thanks to everyone for their assistance.

Shawn

Re: Does haproxy utlize openssl with AES-NI if present?

[Emerson Gomes]

Hello,

If you want "definitive proof" that you're not using AES-NI instructions
during your benchmark, you could simply compile OpenSSL (and then HAproxy,
linking it to this OpenSSL version) passing "-noaes" flag to GCC in the
process.

Then, to make sure your compilation succeeded, check both resulting
binaries (haproxy + libcrypto.so) for any aesni instructions:

$ objdump --disassemble-all libcrypto.so | grep -E 'aes(enc|dec)'

There should be none.

BR.,
Emerson


Em sex., 29 de out. de 2021 às 00:09, Shawn Heisey 
escreveu:

> On 10/28/21 2:11 PM, Lukas Tribus wrote:
> > You would have to run a single request causing a large download, and
> > run haproxy through a cpu profiler, like perf, and compare outputs.
>
> I am learning all sorts of useful things. I see evidence of acceleration
> when pulling a large file with curl!  Average transfer speed is visibly
> lower with acceleration disabled.  First test is haproxy started
> normally, second is haproxy started with the environment variable to
> disable the aes-ni CPU flag:
>
> root@sauron:~# curl --ciphers ECDHE-RSA-AES256-GCM-SHA384
> https://server.domain.tld/4gbrandom > /dev/null
>% Total% Received % Xferd  Average Speed   Time Time Time
> Current
>   Dload  Upload   Total SpentLeft
> Speed
> 100 4096M  100 4096M0 0  63.4M  0  0:01:04  0:01:04 --:--:--
> 63.5M
> root@sauron:~# curl --ciphers ECDHE-RSA-AES256-GCM-SHA384
> https://server.domain.tld/4gbrandom > /dev/null
>% Total% Received % Xferd  Average Speed   Time Time Time
> Current
>   Dload  Upload   Total SpentLeft
> Speed
> 100 4096M  100 4096M0 0  52.2M  0  0:01:18  0:01:18 --:--:--
> 61.4M
>
> The file I transferred is 4GB in size, copied from /dev/urandom with
> dd.  Did the pull from another machine on the same gigabit LAN.  I
> picked the cipher by watching for TLS 1.2 ciphers shown by testssl.sh
> and choosing one that mentioned AES.  The server has plenty of memory to
> cache that entire 4GB file, so disk speed should be irrelevant.
>
> Thank you for hanging onto enough patience to help me navigate this
> rabbit hole.
>
> Thanks,
> Shawn
>
>

Re: Does haproxy utlize openssl with AES-NI if present?

[Willy Tarreau]

On Thu, Oct 28, 2021 at 04:06:42PM -0600, Shawn Heisey wrote:
> The file I transferred is 4GB in size, copied from /dev/urandom with dd. 
> Did the pull from another machine on the same gigabit LAN.  I picked the
> cipher by watching for TLS 1.2 ciphers shown by testssl.sh and choosing one
> that mentioned AES.  The server has plenty of memory to cache that entire
> 4GB file, so disk speed should be irrelevant.
> 
> Thank you for hanging onto enough patience to help me navigate this rabbit
> hole.

By the way on this subject, based on the numbers you reported for
openssl speed, the speed differences on as low bandwidth a network as
1 Gbps are not even relevant. Your machine can encrypt/decrypt at
roughly 2 Gbps per core even when not using AES-NI, so in this case
it's more important to watch the CPU utilization during the transfer
than the transfer speed itself, which can be affected by many other
factors.

Also since you performed your transfer using aes-256-gcm, that's the
one you should test. For me the differences are huge with and without
AES-NI on this algo:

without:
  $ OPENSSL_ia32cap="+0x202" openssl speed -elapsed -evp aes-256-gcm
  type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes 
 16384 bytes
  aes-256-gcm 128654.97k   155005.99k   162485.42k   165428.22k   
166909.27k   166914.73k

with:
  $ openssl speed -elapsed -evp aes-256-gcm
  type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes 
 16384 bytes
  aes-256-gcm 547722.32k  1457707.18k  2632156.25k  3890468.52k  
4604226.22k  4597268.48k

It's almost 30 times faster on large blocks. At 1 Gbps (~118 MB/s), this
machine would spend roughly 70% of CPU in the AES code without AES-NI
versus 2.5% with it. That's where you can see a really measurable
difference.

Of course, like Lukas said, "perf" is very useful here to see where time is
spent.

One trick I often use to measure the effects of micro-optimizations or things
like this that only bring a benefit at higher data rate, is to chain many
haproxy instances so that the traffic is processed many times. I have some
config with 100 instances for example. When your traffic passes 100 times
through decryption/encryption, you can hope to start to measure a big
difference :-)

Willy

Re: Does haproxy utlize openssl with AES-NI if present?

[Shawn Heisey]

On 10/28/21 2:11 PM, Lukas Tribus wrote:

You would have to run a single request causing a large download, and
run haproxy through a cpu profiler, like perf, and compare outputs.


I am learning all sorts of useful things. I see evidence of acceleration 
when pulling a large file with curl!  Average transfer speed is visibly 
lower with acceleration disabled.  First test is haproxy started 
normally, second is haproxy started with the environment variable to 
disable the aes-ni CPU flag:


root@sauron:~# curl --ciphers ECDHE-RSA-AES256-GCM-SHA384 
https://server.domain.tld/4gbrandom > /dev/null
  % Total    % Received % Xferd  Average Speed   Time Time Time  
Current

 Dload  Upload   Total Spent    Left  Speed
100 4096M  100 4096M    0 0  63.4M  0  0:01:04  0:01:04 --:--:-- 
63.5M
root@sauron:~# curl --ciphers ECDHE-RSA-AES256-GCM-SHA384 
https://server.domain.tld/4gbrandom > /dev/null
  % Total    % Received % Xferd  Average Speed   Time Time Time  
Current

 Dload  Upload   Total Spent    Left  Speed
100 4096M  100 4096M    0 0  52.2M  0  0:01:18  0:01:18 --:--:-- 
61.4M


The file I transferred is 4GB in size, copied from /dev/urandom with 
dd.  Did the pull from another machine on the same gigabit LAN.  I 
picked the cipher by watching for TLS 1.2 ciphers shown by testssl.sh 
and choosing one that mentioned AES.  The server has plenty of memory to 
cache that entire 4GB file, so disk speed should be irrelevant.


Thank you for hanging onto enough patience to help me navigate this 
rabbit hole.


Thanks,
Shawn

Re: Does haproxy utlize openssl with AES-NI if present?

[Lukas Tribus]

On Thu, 28 Oct 2021 at 21:20, Shawn Heisey  wrote:
>
> On 10/28/21 10:02 AM, Lukas Tribus wrote:
> > You seem to be trying very hard to find a problem where there is none.
> >
> > Definitely do NOT overwrite CPU flags in production. This is to *test*
> > AES acceleration, I put the link to the blog post in there for
> > context, not because I think you need to force this on.
>
> I wouldn't call this production.  It's the server in my basement. It
> runs most of my personal websites.  I do my experimentation there.  I'm
> OK with those experiments causing the occasional problem, because for
> the most part I know how to fix it if I make a mistake.

I get it. Despite this, I don't want you to make matters worse. Also
other people may read this thread and try the same.



> I did just think of a way that I MIGHT be able to test. Time a simple
> shell script using wget to hit a tiny static web page using https 1
> times.  For that test, the run with haproxy started normally actually
> took longer:

No, that's not the way to test AES-NI. AES-NI doesn't help TLS
handshakes at all. Testing many handshakes and downloads with small
files is exactly the case where AES-NI won't improve anything.

You would have to run a single request causing a large download, and
run haproxy through a cpu profiler, like perf, and compare outputs.

Make sure you run wget that with -O /dev/null and run it on a
different box, so it won't steal CPU from haproxy. Also make sure an
AES cipher is actually negotiated.


Lukas

Re: Does haproxy utlize openssl with AES-NI if present?

[Shawn Heisey]

On 10/28/21 10:02 AM, Lukas Tribus wrote:

You seem to be trying very hard to find a problem where there is none.

Definitely do NOT overwrite CPU flags in production. This is to *test*
AES acceleration, I put the link to the blog post in there for
context, not because I think you need to force this on.


I wouldn't call this production.  It's the server in my basement. It 
runs most of my personal websites.  I do my experimentation there.  I'm 
OK with those experiments causing the occasional problem, because for 
the most part I know how to fix it if I make a mistake.


If all the developers at the various levels (openssl, the openssl 
maintainer for Debian/Ubuntu, and this fine group) did things right, 
then there probably is not a problem.  I started this thread because I 
wanted to ask whether it works the way I hope it does, and at the time I 
couldn't think of a way to test it.


The closest thing I have to production is my server in AWS.  It runs my 
email, and a few websites associated with email, like webmail. Just like 
on the server in my basement, all the websites are behind haproxy.  I 
used to manage production systems running haproxy, but I no longer have 
that job.  On the email server or anything that's actually production, I 
don't the sort of experiments we have been discussing.


I did just think of a way that I MIGHT be able to test. Time a simple 
shell script using wget to hit a tiny static web page using https 1 
times.  For that test, the run with haproxy started normally actually 
took longer:


Starting normally:
real    15m3.545s
user    5m18.367s
sys 8m38.491s

Acceleration disabled:
real    10m49.436s
user    3m52.056s
sys 5m50.564s

That isn't what I expected at all.  I can think of two different 
explanations:


* Haproxy doesn't use openssl in a way that takes advantage of acceleration.
* The way I attempted to disable acceleration is not actually working.

I can try increasing the loop from 1 times to a much larger number.

For the test with acceleration disabled, I manually started haproxy with 
this command after making sure it wasn't running:


OPENSSL_ia32cap="~0x202" /usr/local/sbin/haproxy -Ws -f 
/etc/haproxy/haproxy.cfg -p /run/haproxy.pid &


haproxy -vv output:

HAProxy version 2.4.7-b5e51a5 2021/10/04 - https://haproxy.org/
Status: long-term supported branch - will stop receiving fixes around Q2 
2026.

Known bugs: http://www.haproxy.org/bugs/bugs-2.4.7.html
Running on: Linux 5.11.0-38-generic #42~20.04.1-Ubuntu SMP Tue Sep 28 
20:41:07 UTC 2021 x86_64

Build options :
  TARGET  = linux-glibc
  CPU = native
  CC  = cc
  CFLAGS  = -O2 -march=native -g -Wall -Wextra 
-Wdeclaration-after-statement -fwrapv -Wno-address-of-packed-member 
-Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered 
-Wno-missing-field-initializers -Wno-cast-function-type -Wtype-limits 
-Wshift-negative-value -Wshift-overflow=2 -Wduplicated-cond 
-Wnull-dereference

  OPTIONS = USE_PCRE2_JIT=1 USE_OPENSSL=1 USE_ZLIB=1 USE_SYSTEMD=1
  DEBUG   =

Feature list : +EPOLL -KQUEUE +NETFILTER -PCRE -PCRE_JIT -PCRE2 
+PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED +BACKTRACE 
-STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT 
+CRYPT_H +GETADDRINFO +OPENSSL -LUA +FUTEX +ACCEPT4 -CLOSEFROM +ZLIB 
-SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL 
+SYSTEMD -OBSOLETE_LINKER +PRCTL -PROCCTL +THREAD_DUMP -EVPORTS -OT 
-QUIC -PROMEX -MEMORY_PROFILING


Default settings :
  bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with multi-threading support (MAX_THREADS=64, default=24).
Built with OpenSSL version : OpenSSL 1.1.1f  31 Mar 2020
Running on OpenSSL version : OpenSSL 1.1.1f  31 Mar 2020
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with network namespace support.
Built with zlib version : 1.2.11
Running on zlib version : 1.2.11
Compression algorithms supported : identity("identity"), 
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with transparent proxy support using: IP_TRANSPARENT 
IPV6_TRANSPARENT IP_FREEBIND

Built with PCRE2 version : 10.34 2019-11-21
PCRE2 library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with gcc compiler version 9.3.0

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available multiplexer protocols :
(protocols marked as  cannot be specified using 'proto' keyword)
  h2 : mode=HTTP   side=FE|BE mux=H2 
flags=HTX|CLEAN_ABRT|HOL_RISK|NO_UPG
    fcgi : mode=HTTP   side=BE    mux=FCGI 
flags=HTX|HOL_RISK|NO_UPG

    : mode=HTTP   side=FE|BE mux=H1   flags=HTX
  h1 : mode=HTTP   side=FE|BE mux=H1 flags=HTX|NO_UPG
    : 

Re: Does haproxy utlize openssl with AES-NI if present?

[Lukas Tribus]

On Thu, 28 Oct 2021 at 15:49, Shawn Heisey  wrote:
>
> On 10/28/21 7:34 AM, Shawn Heisey wrote:
> > Does haproxy's use of openssl turn on the same option that the
> > commandline does with the -evp argument?  If it does, then I think
> > everything is probably OK.
>
>
> Running "grep -r EVP ." in the haproxy source tree turns up a lot of
> hits in the TLS/SSL code.  So I think that haproxy is most likely using
> EVP, and since I am running haproxy on bare metal and not in a VM (which
> might mask the aes CPU flag), it probably is using acceleration.  Just
> in case, I did add the openssl bitmap environment variable (the one with
> + instead of ~) to my haproxy systemd unit.

You seem to be trying very hard to find a problem where there is none.

Definitely do NOT overwrite CPU flags in production. This is to *test*
AES acceleration, I put the link to the blog post in there for
context, not because I think you need to force this on.


You cannot compare command line arguments of an openssl tool with
openssl library API calls, those are two different things.

If this keeps you up at night, I'd suggest you ask on the
openssl-users mailing list for clarification, or set brakepoints in
gdb and debug openssl when running from haproxy, or find a platform
where you have both a CPU with and without aesni support, and compile
openssl and haproxy with aesni and then move the executable over. It
will be a waste of your time though.


Lukas

Re: Does haproxy utlize openssl with AES-NI if present?

[Shawn Heisey]

On 10/28/21 7:34 AM, Shawn Heisey wrote:
Does haproxy's use of openssl turn on the same option that the 
commandline does with the -evp argument?  If it does, then I think 
everything is probably OK. 



Running "grep -r EVP ." in the haproxy source tree turns up a lot of 
hits in the TLS/SSL code.  So I think that haproxy is most likely using 
EVP, and since I am running haproxy on bare metal and not in a VM (which 
might mask the aes CPU flag), it probably is using acceleration.  Just 
in case, I did add the openssl bitmap environment variable (the one with 
+ instead of ~) to my haproxy systemd unit.


Thanks,
Shawn

Re: Does haproxy utlize openssl with AES-NI if present?

[Shawn Heisey]

On 10/28/21 12:31 AM, Lukas Tribus wrote:

You want evidence.


That would be preferred, yes.

Then get a raspberry pi, and run haproxy manually, fake the cpu flag 
aes-ni and it should crash when using aes acceleration, because the 
cpu doesn't support it.


https://romanrm.net/force-enable-openssl-aes-ni-usage 




That page seemed to indicate that if openssl detects the CPU flag, it 
will use it, at least with Tor, the software being used by the author of 
the article.


Does haproxy's use of openssl turn on the same option that the 
commandline does with the -evp argument?  If it does, then I think 
everything is probably OK.


Something interesting to note:  In the 3.0.1-dev version, the test I 
started with (running without -evp and then again with -evp) doesn't 
show a speed difference.  So whatever -evp does is on by default in the 
latest openssl.  I'm very interested in seeing openssl 3 support in haproxy.


Thanks,
Shawn

Re: Does haproxy utlize openssl with AES-NI if present?

[Lukas Tribus]

On Thu, 28 Oct 2021 at 08:31, Lukas Tribus  wrote:
>
> Hi,
>
> On Thursday, 28 October 2021, Shawn Heisey  wrote:
>>
>> On 10/27/2021 2:54 PM, Lukas Tribus wrote:
>>>
>>> I'd be surprised if the OpenSSL API calls we are using doesn't support 
>>> AES-NI.
>>
>>
>> Honestly that would surprise me too.  But I have no idea how to find out 
>> whether it's using the acceleration or not, and the limited (and possibly 
>> incorrect) evidence I had suggested that maybe it was disabled by default, 
>> so I wanted to ask the question.  I have almost zero knowledge about openssl 
>> API or code, so I can't discern the answer from haproxy code.
>
>
>
> You want evidence.
>
> Then get a raspberry pi, and run haproxy manually, fake the cpu
> flag aes-ni and it should crash when using aes acceleration,
> because the cpu doesn't support it.

For some reason, openssl itself doesn't crash on my raspberry pi:
OPENSSL_ia32cap="+0x202" openssl speed -elapsed -evp aes-128-gcm

Most likely openssl is compiled without aes-ni support here, so the
test doesn't work.

Lukas

Re: Does haproxy utlize openssl with AES-NI if present?

[Lukas Tribus]

Hi,

On Thursday, 28 October 2021, Shawn Heisey  wrote:

> On 10/27/2021 2:54 PM, Lukas Tribus wrote:
>
>> I'd be surprised if the OpenSSL API calls we are using doesn't support
>> AES-NI.
>>
>
> Honestly that would surprise me too.  But I have no idea how to find out
> whether it's using the acceleration or not, and the limited (and possibly
> incorrect) evidence I had suggested that maybe it was disabled by default,
> so I wanted to ask the question.  I have almost zero knowledge about
> openssl API or code, so I can't discern the answer from haproxy code.



You want evidence.

Then get a raspberry pi, and run haproxy manually, fake the cpu flag aes-ni
and it should crash when using aes acceleration, because the cpu doesn't
support it.

https://romanrm.net/force-enable-openssl-aes-ni-usage


Lukas

Re: Does haproxy utlize openssl with AES-NI if present?

[Christopher Cox]

On 10/27/21 5:47 PM, Shawn Heisey wrote:

On 10/27/2021 2:54 PM, Lukas Tribus wrote:

I'd be surprised if the OpenSSL API calls we are using doesn't support AES-NI.


Honestly that would surprise me too.  But I have no idea how to find out whether 
it's using the acceleration or not, and the limited (and possibly incorrect) 
evidence I had suggested that maybe it was disabled by default, so I wanted to 
ask the question.  I have almost zero knowledge about openssl API or code, so I 
can't discern the answer from haproxy code.


openssl uses AES-NI acceleration if present and enabled (which it should be). 
Since most all Intel nowadays has it, you can actually see the difference when 
using something like ssh for xfers using a cipher like aes128-...@openssh.com 
(the perf difference is very noticable).


I mean, my experience is limited to using openSSH, but would think it would be 
applicable elsewhere.




Thanks for the improved commands for testing purposes.

On openssl 1.1.1 from ubuntu, first with acceleration disabled and then with it 
enabled:


type 16 bytes 64 bytes    256 bytes   1024 bytes   8192 bytes  
16384 bytes
aes-128-cbc 175183.68k   218351.02k   242778.28k   251637.42k 231298.39k   
251587.24k


type 16 bytes 64 bytes    256 bytes   1024 bytes   8192 bytes  
16384 bytes
aes-128-cbc 302331.09k   443021.42k   475877.63k   486907.90k 487268.35k   
489406.46k



The same with openssl 3.0.1-dev:

type 16 bytes 64 bytes    256 bytes   1024 bytes   8192 bytes  
16384 bytes
AES-128-CBC 190766.02k   216849.62k   245917.61k   202468.01k 250989.23k   
225902.59k


type 16 bytes 64 bytes    256 bytes   1024 bytes   8192 bytes  
16384 bytes
AES-128-CBC 348296.06k   404943.64k   480815.70k   485857.96k 423469.06k   
480007.51k


That is great data, but doesn't tell me whether openssl uses acceleration in 
haproxy.


---

Separate but indirectly related:  I would like to know if there is a timeline 
for when openssl 3.x will be supported by haproxy.  The 2.4.7 version won't even 
compile against my local install of 3.0.1-dev.  The 2.5-dev11 version compiles, 
but fails to link.  I would imagine that it's going to be a lot of work to 
support it.


Thanks,
Shawn

Re: Does haproxy utlize openssl with AES-NI if present?

[Shawn Heisey]

On 10/27/2021 2:54 PM, Lukas Tribus wrote:

I'd be surprised if the OpenSSL API calls we are using doesn't support AES-NI.


Honestly that would surprise me too.  But I have no idea how to find out 
whether it's using the acceleration or not, and the limited (and 
possibly incorrect) evidence I had suggested that maybe it was disabled 
by default, so I wanted to ask the question.  I have almost zero 
knowledge about openssl API or code, so I can't discern the answer from 
haproxy code.


Thanks for the improved commands for testing purposes.

On openssl 1.1.1 from ubuntu, first with acceleration disabled and then 
with it enabled:


type 16 bytes 64 bytes256 bytes   1024 bytes   8192 
bytes  16384 bytes
aes-128-cbc 175183.68k   218351.02k   242778.28k   251637.42k 
231298.39k   251587.24k


type 16 bytes 64 bytes256 bytes   1024 bytes   8192 
bytes  16384 bytes
aes-128-cbc 302331.09k   443021.42k   475877.63k   486907.90k 
487268.35k   489406.46k



The same with openssl 3.0.1-dev:

type 16 bytes 64 bytes256 bytes   1024 bytes   8192 
bytes  16384 bytes
AES-128-CBC 190766.02k   216849.62k   245917.61k   202468.01k 
250989.23k   225902.59k


type 16 bytes 64 bytes256 bytes   1024 bytes   8192 
bytes  16384 bytes
AES-128-CBC 348296.06k   404943.64k   480815.70k   485857.96k 
423469.06k   480007.51k


That is great data, but doesn't tell me whether openssl uses 
acceleration in haproxy.


---

Separate but indirectly related:  I would like to know if there is a 
timeline for when openssl 3.x will be supported by haproxy.  The 2.4.7 
version won't even compile against my local install of 3.0.1-dev.  The 
2.5-dev11 version compiles, but fails to link.  I would imagine that 
it's going to be a lot of work to support it.


Thanks,
Shawn

Re: Does haproxy utlize openssl with AES-NI if present?

[Lukas Tribus]

Hello,


On Wed, 27 Oct 2021 at 22:17, Shawn Heisey  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="~0x202" 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

Does haproxy utlize openssl with AES-NI if present?

[Shawn Heisey]

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.


My question is ... will haproxy use the CPU crypto acceleration with 
stock Ubuntu openssl if the

hardware supports it?  I would have tested it if I could figure out how.

Thanks,
Shawn