2024-06-03 02:34:58

by Sergey Senozhatsky

[permalink] [raw]
Subject: Re: [PATCH 1/3] crypto: scomp - Add setparam interface

On (24/06/01 11:54), Herbert Xu wrote:
> On Sat, Jun 01, 2024 at 09:24:15AM +0900, Sergey Senozhatsky wrote:
> >
> > Is it possible to share a tfm? I thought that tfm-s carry some state
> > (compression workmem/scratch buffer) so one cannot do parallel compressions
> > on different CPUs using the same tfm.
>
> Yes the tfm can be shared. The data state is kept in the request
> object.

Oh, nice, thanks.

I'll try that new API (and tfm sharing) in zram, coordinate with
android folks on this and will come back to you.


2024-06-03 08:29:14

by Sergey Senozhatsky

[permalink] [raw]
Subject: Re: [PATCH 1/3] crypto: scomp - Add setparam interface

On (24/06/03 11:34), Sergey Senozhatsky wrote:
> On (24/06/01 11:54), Herbert Xu wrote:
> > On Sat, Jun 01, 2024 at 09:24:15AM +0900, Sergey Senozhatsky wrote:
> > >
> > > Is it possible to share a tfm? I thought that tfm-s carry some state
> > > (compression workmem/scratch buffer) so one cannot do parallel compressions
> > > on different CPUs using the same tfm.
> >
> > Yes the tfm can be shared. The data state is kept in the request
> > object.
>
> Oh, nice, thanks.

Herbert, I'm not sure I see how tfm sharing is working.

crypto_tfm carries a pointer to __crt_ctx, which e.g. for zstd
is struct zstd_ctx, where it keeps all the state (zstd_cctx, zstd_dctx,
and compression/decompression workmem buffers).

When we call crypto_comp_compress()->zstd_compress() we just pass tfm,
then the driver gets tfm-s state/ctx via crypto_tfm_ctx() and uses it
for underlying compression library call.