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
