On Wed, Jun 25, 2025 at 08:44:45AM -0400, Theodore Ts'o wrote: > On Tue, Jun 24, 2025 at 11:32:52PM -0700, 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! > > I wonder if the primary design goal of the STM32 crypto engine is that > it might reduce power consumption --- after all, one of the primary > benchmarketing metrics that vendors care about is "hours of You Tube > watch time" --- and decryptoing a video stream doesn't require high > performance. > > Given that the typical benchmarketing number which handset vendors > tend to care about is SQLite transactions per second, maybe they > wouldn't be all that eager to use the crypto engine. :-) >
My STM32MP157F-DK2 board (with screen removed) is pulling 1.5W regardless of whether it's running the benchmark with the STM32 crypto engine or with the NEON bit-sliced code. However, the NEON bit-sliced code finishes 5 times faster. - Eric _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
