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

[Leonid Ravich <lravich@amazon.com>]

On Mon, Jul 13, 2026 at 12:25:35PM +1000, Herbert Xu wrote:
> This shouldn't be a template.  The default data-unit handling
> should go into the mid-API layer (so skcipher.c).  It should
> transparently split things up *if* the underlying algorithm does
> not support multiple units.

Done for v6 (mid-API split in skcipher.c, cherry-picking  acomp
CRYPTO_ALG_REQ_SEG / segmentation-wrapper patch as you suggested).  One
design fork I'd like your call on before I resend.

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.

  2. HW-offload-hint model (as in Inel acomp series): callers set
     unit_size only for CRYPTO_ALG_REQ_SEG algs and the mid-API never
     emulates non-native ones.  Zero overhead, but the path is dead
     until an in-tree skcipher advertises native support, unlike
     acomp, where IAA already does.

(1) is usable now with a small permanent SW cost; (2) mirrors the acomp
mid-layer dispatch but, absent a native skcipher, ships an interface
with no in-tree user.  Which would you prefer?

Thanks,
Leonid