Re: [PATCH v5 2/5] crypto: dun - data-unit-number dispatch template

[Herbert Xu <herbert@gondor.apana.org.au>]

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 <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt