Hi,
On 6/25/25 08:32, Eric Biggers wrote:
That was the synchronous throughput. However, submitting multiple requests
asynchronously (which again, fscrypt doesn't actually do) barely helps.
Apparently the STM32 crypto engine has only one hardware queue.
I already strongly suspected that these non-inline crypto engines aren't worth
using. But I didn't realize they are quite this bad. Even with AES on a
Cortex-A7 CPU that lacks AES instructions, the CPU is much faster!
From a performance perspective, using hardware crypto offloads the CPU,
which is important in real-world applications where the CPU must handle
multiple tasks. Our processors are often single-core and not the highest
performing, so hardware acceleration is valuable.
I can show you performance test realized with openSSL (3.2.4) who shows,
less CPU usage and better performance for large block of data when our
driver is used (via afalg):
command used: ```openssl speed -evp aes-256-cbc -engine afalg -elapsed```
+--------------------+--------------+-----------------+
| Block Size (bytes) | AFALG (MB/s) | SW BASED (MB/s) |
+--------------------+--------------+-----------------+
| 16 | 0.09 | 9.44 |
| 64 | 0.34 | 11.43 |
| 256 | 1.31 | 12.08 |
| 1024 | 4.96 | 12.27 |
| 8192 | 18.18 | 12.33 |
| 16384 | 22.48 | 12.33 |
+--------------------+--------------+-----------------+
to test CPU usage I've used a monocore stm32mp157f.
here with afalg, we have an average CPU usage of ~75%, with the sw based
approach CPU is used at ~100%
Maxime
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
