[Swan] Using AES-NI doesn't improve performance in most cases

[Alex Elsayed]

Andreas Herz wrote:

> Hi,
> 
> as advised by Tuomo i build a test setup, one with fedora20 and one with
> recent centos.
> 
> In both cases i have libreswan 3.8 active and fedora20 with 3.12 and
> centos with 2.6.32 kernel. The CPU does support AES-NI and the module is
> loaded, it also increases performance when i test it with cryptsetup for
> example.
> 
> Now what i get is the following behaviour:
> 
> 3.12/Fedora:
> 
> AES-NI loaded + NETKEY: ~280mbit/s
> AES-NI unloaded + NETKEY: ~280mbit/s
> AES-NI loaded + KLIPS: ~280mbit/s
> AES-NI unloaded + KLIPS: ~280mbit/s
> 
> 
> 2.6.32/CentOS:
> 
> AES-NI loaded + NETKEY: ~280mbit/s
> AES-NI unloaded + NETKEY: ~280mbit/s
> AES-NI loaded + KLIPS: ~370mbit/s
> AES-NI unloaded + KLIPS: ~280mbit/s
> 
> As you can see, the only case with increasing performance is AES-NI
> loaded and KLIPS.
> 
> So i though AES-NI isn't used in the other cases although the module is
> loaded. So i added debug infos into the aes-ni module, to be more
> precise in arch/x86/crypto/aesni-intel_glue.c and with that i see, that
> also in the other cases the module is really used but no increase.
> I also can't see any difference, they all call the "aes_encrypt" and
> "aes_decrypt" function. What is not called is for example
> "__driver_rfc4106_encrypt" but since the working KLIPS case doesn't call
> it either i guess it's not necessary.
> 
> So does anyone have an idea why AES-NI isn't working that well?
> Does anyone have a working setup with AES-NI improving the performance?
> 
> My goal is to get libreswan+KLIPS+AES-NI working with a recent 3.X
> kernel and to achieve the expected performance increase.
> 
> Thanks!
> 

Well, your throughput may not be increasing in the tests you ran, but what's 
the load like? It may be that the crypto isn't the _bottleneck_ (and thus 
making the crypto faster won't result in better benchmarks), but saving 
resources that might otherwise be spent on crypto for other things may still 
be valuable.