On Wed, Jul 15, 2026 at 12:01:02PM +0000, Leonid Ravich wrote: > > I benchmarked the mid-API split vs the legacy per-sector loop on > r7i.metal (VAES-AVX512): dm-crypt shows no measurable throughput or > latency regression, but a microbench isolates a fixed ~50 ns per 512B > unit. It's a fixed per-call cost: the split > copies the counter IV to a per-unit scratch and re-walks the sglist per > unit and is paid only by callers setting unit_size != 0. > That gives two directions: > > 1. SW batching layer (current v6): mid-API transparently splits when > the alg lacks CRYPTO_ALG_REQ_SEG and unit_size != 0. > Works today on every existing skcipher at the ~50 ns/unit cost, > and goes quiet as algs gain native support.
I think we should be able to eliminate this overhead. Could you send me the patch so I can take a look? But going back to the dun template, I think we should still go with no templates for plain64. But the other ones should use a template instead of using the cc->iv_gen_ops->generator. IOW if unit-splitting is in use, dm-crypt should always pass the sector number in little-endian format in as the IV. Then depending on which IV generator is configured (which should be done through templates, just like essiv), they can generate the final IV. With this scheme, there should be no overall increase in indirect calls in any case (and with one less for plain64). This still preserves the ability for optimised implementations to eliminate indirect calls for the IV generator by handling it directly rather than through the generic template. Thanks, -- Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
