On Tue, Jun 16, 2026 at 12:13:03PM +0800, Herbert Xu wrote: > On Mon, Jun 15, 2026 at 03:53:17PM -0700, Eric Biggers wrote: > > > > So in other words, this series slows down dm-crypt and crypto_skcipher > > for everyone to optimize for an out-of-tree driver. And there's also no > > benchmark showing that your driver is even worth it over just using the > > CPU. > > There is no reason why the software fallback should be slower > than the status quo. Existing callers of the Crypto API will > be issuing one indirect function call per data unit. With the > new scheme, the indirect calls per unit moves from from the caller > into the Crypto API.
Have you checked the code? This patchset adds overhead in multiple places. Dynamically allocating multiple scatterlists and then parsing them, adding a new field to skcipher_request for everyone, new checks in crypto_skcipher_en/decrypt for everyone, new checks to validate the data unit size that the caller knew was valid in the first place, etc. > In fact, we could move it down further and improve upon the > status quo by splitting the data in each algorithm implemntation > so that the calls per unit become direct function calls and only > the overall call into the Crypto API remains indirect. That's not what this patchset does. But also, as we know, a better way to eliminate "Crypto API" overhead is to call the algorithms directly. - Eric
