[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250625124445.GC28249@mit.edu>
Date: Wed, 25 Jun 2025 08:44:45 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Simon Richter <Simon.Richter@...yros.de>, linux-fscrypt@...r.kernel.org,
linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mtd@...ts.infradead.org, linux-ext4@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net, ceph-devel@...r.kernel.org
Subject: Re: [PATCH] fscrypt: don't use hardware offload Crypto API drivers
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. :-)
- Ted
Powered by blists - more mailing lists