Maybe you can set one with these options to bench it, I couldn’t find phoronix ones…
Ah! Sorry, I’m on day two of an intense migraine and am not braining well. That and I’d yet to learn anything about kernel modules before installing the test one you made in the other thread.
So, I’d be able to install that module, using the instructions you gave in the other thread, without downgrading kernels, once I install this one from the unstable branch?
Apologies if I’m still not getting it.
Drink some goat’s milk.
1 Like
I will definitely try this.
Luckily it’s abating, finally.
We can try it as an experiment when 5.12 hits the RPi tree and let everyone experiment with it and decide if it is the way we want to go.
Hey! We had a commit! I tested the loading of the available AES modules a week ago and they are correct, they run more slowly. More slowly than not loading them, which I thought quite odd. Looks like the aes_arm64 is the faster module and I think this patch makes sure it is selected before the others.
My question is, once this patch hits, could we maybe have CONFIG_CRYPTO_AES_ARM64=y set?
Also a big merge this morning for 5.10.y, seems like kernel development is starting to heat up again.
The latest linux-rpi4 has been pushed to the unstable branch when the mirrors sync.
Done and I also patched the kernel so zoom works properly in Kodi.
Although they have not upgraded to the latest kernel yet involving the 2 raspberrypi-bootloader packages they did fix yesterday something they broke involving getting EDID info from monitors so I have pushed those new packages also.
https://github.com/raspberrypi/firmware/issues/1548
linux-rpi4 5.10.22-1
linux-rpi4 headers-5.10.22-1
raspberrypi-bootloader 20210311-1t
raspberrypi-bootloader-x 20210311-1
2 Likes
To clarify, is CONFIG_CRYPTO_AES_ARM64=y set in the 5.10.22-1 build or it will be set for the next build?
Yes it is done.
1 Like
Wow, that was fast, thank you!
Do you know a way to bench it ?
For aes-adiantum I knew these commands :
cryptsetup benchmark -c xchacha12,aes-adiantum
cryptsetup benchmark -c xchacha20,aes-adiantum
No, sorry. I was not precise in my testing. We have an app that does a lot of encrypting and decrypting of documents and I simply checked the performance with the AES modules loaded and unloaded. Had I known about the patch and how the AES modules were selected, I would have tested more. It was more or less just a test to see if loading the AES modules improved the performance, which it did not. The app ran slower.
After seeing this patch, I assume one of the slower modules was being called rather than the aes_arm64 module. More testing to come.
One of these days, I will get around to testing the CONFIG_CRYPTO_SHA*_ARM64 modules to see if one can improve the throughput of SSH.
With the new kernel 5.10.22, I’ve tested this command :
cryptsetup benchmark
(without parameters)
I can see a aes-cbc encryption improvment : roughly multiplied by 3 for 128bits and 256 bits, all others are unchanged.
I think you should see some improvments .
Edit : do you know which algorithm your software use ? (the benchmark show me that serpent is disabled, but I do not think its one of your “requirements” because it is a little bit “specific”)
1 Like
My understanding is that aes-cbc is used in the app, so excellent news indeed. Thank you
These are the results of running cryptsetup benchmark
with cryptsetup 2.3.4-2 (noted as there is an update, but not yet applied)
5.10.20-1-MANJARO-ARM
PBKDF2-sha1 484554 iterations per second for 256-bit key
PBKDF2-sha256 768750 iterations per second for 256-bit key
PBKDF2-sha512 612485 iterations per second for 256-bit key
PBKDF2-ripemd160 400219 iterations per second for 256-bit key
PBKDF2-whirlpool 149796 iterations per second for 256-bit key
argon2i 4 iterations, 281498 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id 4 iterations, 275206 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 25.4 MiB/s 90.9 MiB/s
serpent-cbc 128b N/A N/A
twofish-cbc 128b 66.6 MiB/s 67.9 MiB/s
aes-cbc 256b 20.6 MiB/s 69.2 MiB/s
serpent-cbc 256b N/A N/A
twofish-cbc 256b 68.1 MiB/s 67.8 MiB/s
aes-xts 256b 99.2 MiB/s 88.6 MiB/s
serpent-xts 256b N/A N/A
twofish-xts 256b 72.0 MiB/s 73.1 MiB/s
aes-xts 512b 76.5 MiB/s 68.0 MiB/s
serpent-xts 512b N/A N/A
twofish-xts 512b 75.1 MiB/s 73.0 MiB/s
5.10.22-1-MANJARO-ARM
PBKDF2-sha1 479239 iterations per second for 256-bit key
PBKDF2-sha256 779031 iterations per second for 256-bit key
PBKDF2-sha512 613202 iterations per second for 256-bit key
PBKDF2-ripemd160 399609 iterations per second for 256-bit key
PBKDF2-whirlpool 149284 iterations per second for 256-bit key
argon2i 4 iterations, 292055 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id 4 iterations, 291995 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 81.6 MiB/s 94.7 MiB/s
serpent-cbc 128b N/A N/A
twofish-cbc 128b 67.3 MiB/s 67.8 MiB/s
aes-cbc 256b 73.4 MiB/s 75.6 MiB/s
serpent-cbc 256b N/A N/A
twofish-cbc 256b 68.6 MiB/s 68.0 MiB/s
aes-xts 256b 89.4 MiB/s 105.6 MiB/s
serpent-xts 256b N/A N/A
twofish-xts 256b 72.2 MiB/s 73.0 MiB/s
aes-xts 512b 80.9 MiB/s 81.7 MiB/s
serpent-xts 512b N/A N/A
twofish-xts 512b 75.2 MiB/s 72.9 MiB/s
A very nice improvement for aes-cbc encryption and a worthwhile improvement for aes-cbc decryption.
1 Like
Is your device overclocked ? That’s 15% more than mine.