Poor dm-crypt benchmark on STM32MP157

[johnnyc]

What kind of encryption performance can we expect from the cryptoprocessor? SoC is STM32MP157 with kernel 5.10. Currently we get: 

root@host:~# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1        57186 iterations per second for 256-bit key
PBKDF2-sha256      84453 iterations per second for 256-bit key
PBKDF2-sha512      52512 iterations per second for 256-bit key
PBKDF2-ripemd160   47558 iterations per second for 256-bit key
PBKDF2-whirlpool   11425 iterations per second for 256-bit key
argon2i       4 iterations, 31804 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 32529 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
[  199.200180] sched: RT throttling activated
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b         4.1 MiB/s         4.1 MiB/s
    serpent-cbc        128b               N/A               N/A
    twofish-cbc        128b               N/A               N/A
        aes-cbc        256b         4.1 MiB/s         4.1 MiB/s
    serpent-cbc        256b               N/A               N/A
    twofish-cbc        256b               N/A               N/A
        aes-xts        256b         4.0 MiB/s         4.1 MiB/s
    serpent-xts        256b               N/A               N/A
    twofish-xts        256b               N/A               N/A
        aes-xts        512b         4.1 MiB/s         4.0 MiB/s
    serpent-xts        512b               N/A               N/A
    twofish-xts        512b               N/A               N/A

When using the CPU instead of the cryptoprocessor we get:

root@host:~# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1        57893 iterations per second for 256-bit key
PBKDF2-sha256      84128 iterations per second for 256-bit key
PBKDF2-sha512      52597 iterations per second for 256-bit key
PBKDF2-ripemd160   47766 iterations per second for 256-bit key
PBKDF2-whirlpool   11397 iterations per second for 256-bit key
argon2i       4 iterations, 32573 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 32866 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b        12.5 MiB/s        14.4 MiB/s
    serpent-cbc        128b               N/A               N/A
    twofish-cbc        128b               N/A               N/A
        aes-cbc        256b         9.9 MiB/s        10.5 MiB/s
    serpent-cbc        256b               N/A               N/A
    twofish-cbc        256b               N/A               N/A
        aes-xts        256b        15.9 MiB/s        13.9 MiB/s
    serpent-xts        256b               N/A               N/A
    twofish-xts        256b               N/A               N/A
        aes-xts        512b        12.3 MiB/s        10.7 MiB/s
    serpent-xts        512b               N/A               N/A
    twofish-xts        512b               N/A               N/A

The kernel message

[ 199.200180] sched: RT throttling activated

during the cryptoprocessor benchmark is strange. It does not happen, when doing file transfers on the encrypted target, though.

Can anyone from ST please evaluate these values? @Community member​ @Sara BEN HADJ YAHYA​ 

[Olivier GALLIEN]

Hi @johnnyc​ 

Your results looks inline with what have been already reported and analyze in some other thread like this one :

https://community.st.com/s/question/0D53W00001JUAMJSA5/issues-with-crypto-ip-core

Its conclusion is still valid :

ST policy about Linux is to rely on Linux framework + HW driver adaptations to these framework to better upstream an overall solution maintained by the community (and therefore giving more sustainability of ST solution for customers).

Doing this for Cryptodev framework shows the results you highlight here: for some cases, performances are very low compared to full cpu and with the same cpu load ....

A study is ongoing to check what could be done to improve this (depending on HW capability and SW adaptation required on top of HW drivers) but there is no short term solution.

Olivier

[yossefhaycohen]

Hi @Olivier GALLIEN 

Did you performed improvements?

Thanks