OpenSSL 1.0.1 and AES-NI
-
There are already a couple of posts about openssl with aes-ni on this forum. As they don't show me a clear picture, I just tested myself the openssl performance with the current LiveCD pfSense 2.1-BETA1-amd64-20130407-0250 being installed as KVM VM (plain, without any virtio or further configurations). The host has a Intel Core i7-3770 3.4GHz CPU with the 'aes'/AES-NI feature always enabled for all VMs.
Result: openssl 1.0.1e has the aes-ni performance only if the crypto hw setting is set to none and the aesni.ko module is not loaded (scenario 2). Is this a bug or expected behavior?
Scenario 1: pfSense with module, but no performance dmesg: aesni0 <aes-cbc,aes-xts> on motherboard kldstat: aesni.ko loaded Crypto HW: AES-NI CPU-based Acceleration –---------------------------------------------------- /usr/bin/openssl speed -evp aes-128-cbc -elapsed OpenSSL 0.9.8y 5 Feb 2013 type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 15112.61k 56426.88k 174954.66k 372524.95k 236635.04k /usr/local/bin/openssl speed -evp aes-128-cbc -elapsed OpenSSL 1.0.1e 11 Feb 2013 type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 15003.38k 56277.06k 174802.81k 371585.72k 229122.01k</aes-cbc,aes-xts>Scenario 2: pfSense without module, but with same performance as the host dmesg: aesni0 <aes-cbc,aes-xts> on motherboard kldstat: no aesni.ko Crypto HW: None –---------------------------------------------------- /usr/bin/openssl speed -evp aes-128-cbc -elapsed OpenSSL 0.9.8y 5 Feb 2013 type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 164469.41k 182946.87k 191618.21k 196323.05k 197930.83k /usr/local/bin/openssl speed -evp aes-128-cbc -elapsed OpenSSL 1.0.1e 11 Feb 2013 type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 615347.13k 655957.97k 667286.62k 668656.00k 670887.10k <===</aes-cbc,aes-xts>Scenario 3: host itself or other Linux VMs and openssl 1.0.1x –---------------------------------------------------- openssl speed -evp aes-128-cbc -elapsed OpenSSL 1.0.1c 10 May 2012 type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 616457.53k 657153.13k 667808.43k 670501.55k 671312.55k -
As a followup, I quickly tested the speed of openvpn (ip fastforwarding enabled):
knoppix VM –(openVPN)--> pfsense VM ---> Internet ---> download mirrorwithout openvpn: 45MB/s
with openvpn, without aesni.ko: 4-6MB/s, 30-40% CPU
with openvpn, with aesni.ko: 4-6MB/s, 30-40% CPUIs the openvpn of pfSense using the aes-ni at all?
-
I split this off into its own topic since it is more of an AES-NI question than directly related to that other thread.
We have observed some similar issues (see the other threads about AES-NI, especially http://forum.pfsense.org/index.php/topic,54008.0.html ) but we don't have any AES-NI capable hardware in our lab yet to tinker with.
Having the AES-NI module loaded hooks into the crypto system of FreeBSD so that IPsec can take advantage of it, and OpenVPN will latch on as well.
OpenSSL 1.0.1e does have its own AES-NI code, but the way it selects its engine is based on which ciphers have registered engines. If there is an engine that offers to support AES, it will be used over OpenSSL's internal code. That explains why it is slower with AES-NI loaded no matter what you select in the OpenVPN engine list.
In this case it would appear that OpenSSL's internal code handles AES-NI better than FreeBSD's crypto engine hooking into AES-NI but why that is the case exactly, I'm not sure. There may be some other bit for FreeBSD's AES-NI code that we're missing or that needs setup/optimized in some way.
