On Mon, Apr 27, 2026 at 09:56:22AM +0000, Leonid Ravich wrote:
>
> Proposal
> ========
> 
> Add a data_unit_size field to struct skcipher_request:
> 
>   struct skcipher_request {
>       unsigned int cryptlen;
>       u8 *iv;
>       struct scatterlist *src;
>       struct scatterlist *dst;
> +     unsigned int data_unit_size;
>       struct crypto_async_request base;
>       void *__ctx[] CRYPTO_MINALIGN_ATTR;
>   };
> 
> When data_unit_size is 0, behavior is unchanged (cryptlen is one
> data unit). When data_unit_size is nonzero, cryptlen must be a
> multiple of data_unit_size. The IV applies to the first data unit.
> The crypto driver is responsible for incrementing the tweak per
> data unit according to the mode.
> 
> This mirrors the data_unit_size concept already present in struct
> blk_crypto_config for inline encryption. In blk-crypto the size
> is a property of the key configuration. Here it is per-request
> because dm-crypt may use different sector sizes across different
> device-mapper tables sharing the same tfm.

Yes I'm happy with this since it could also work for IPsec.

But before you invest too much energy in it it would be helpful
if you can get some proof-of-concept performance numbers so that
your effort is not wasted down the track.

Thanks,
-- 
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Reply via email to