Re: [v3 PATCH 3/8] crypto: acomp - Move stream management into scomp layer

[Eric Biggers <ebiggers@kernel.org>]

On Sun, Mar 09, 2025 at 10:43:17AM +0800, Herbert Xu wrote:
> Rather than allocating the stream memoryin the request object,
> move it into a per-cpu buffer managed by scomp.  This takes the
> stress off the user from having to manage large request objects
> and setting up their own per-cpu buffers in order to do so.

Well, except the workspace (which you seem to be calling a "stream" for some
reason) size depends heavily on the compression parameters, such as the maximum
input length and compression level.  Zstd for example wants 1303288 (comp) +
95944 (decomp) with the parameters the crypto API is currently setting, but only
89848 + 95944 if it's properly configured with estimated_src_size=4096 which is
what most of the users actually want.  So making this a per-algorithm property
is insufficiently flexible.

But of course there is also no guarantee that users want it to be per-"tfm"
either, let alone have a full set of per-CPU buffers.  FWIW, this series makes
the kernel use an extra 40 MB of memory on my system if I enable
CONFIG_UBIFS_FS, which seems problematic.

I don't think the crypto API model works well for compression at all, TBH.

- Eric