Using hardware accelaration for dm-crypt AES on BBB

GoogleGroups
1

I’m trying to use the HW AES acceleration on BBB with dm-crypt.

So far my results have been mixed (see also https://github.com/beagleboard/kernel/issues/68):

While it didn’t work at all on 3.8 kernels, with 3.12 kernels there were no errors, but I could not find any indications that dm-crypt is using the HW AES and the performance was less then expected (about 13MB/s measured with the methods described in the TI wiki linked below).

I then tried the 3.2 kernel from TI:

http://processors.wiki.ti.com/images/8/80/Enabling_DM_Crypt_V4_SDK6_00.pdf

Unfortunately, I again could not reach the performance described here (about 13MB/s):

http://processors.wiki.ti.com/index.php/AM335x_Crypto_Performance#AM335x_1GHz_OPP_Frequency

but the method described in the PDF to verify that the HW AES is used suggested that it was the case (lots of edma interrupts generated).

Now I’m a bit surprised: I’ve switched to the newest Ubuntu saucy image from Robert (again with a 3.12 kernel installed), and the performance is way higher (above 20MB/s) than listed in the TI wiki for HW accelerated dm-crypt, but this is again seems to be without the HW AES being used (performance does not depend on HW AES driver enabled/no edma interrupts generated even if it is enabled).

If anyone has thoughts or comments on this, I’d be happy to hear them.

In the meantime I’ll try to investigate further.

2

Ok, first of all, the transfer speeds obtained with hdparm with the saucy image seem to be unrealistic, because cross checks with dd on files again show much lower speeds (maybe some compiler optimization at work here?).

Secondly, I now have a pointer why HW acceleration is not working: There was no corresponding entry in the am33xx.dtsi … but it is there now (http://lkml.org/lkml/2013/9/30/624). So let’s see if I can build a working 3.13 Kernel …

3

I can confirm that HW acceleration is working with 3.13-rc3 … however it is way slower (9 MB/s) than the SW AES, especially the new NEON optimized AES (CONFIG_CRYPTO_AES_ARM_BS).

4

maybe a compiler flag difference in the packages such as one was built
with 03 the other 02?

Just a guess

5

Apparently, it’s unrealistic to expect good performance from dm-crypt with HW acceleration, given that it uses a block size of 512 bytes:

http://code.google.com/p/cryptsetup/issues/detail?id=150