All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] crypto: passing configuration parameters to comp algos
Date: Tue, 30 Apr 2024 12:28:00 +0900	[thread overview]
Message-ID: <20240430032800.GF14947@google.com> (raw)
In-Reply-To: <20240430031847.GB10165@sol.localdomain>

On (24/04/29 20:18), Eric Biggers wrote:
> On Tue, Apr 30, 2024 at 12:04:47PM +0900, Sergey Senozhatsky wrote:
> > Hi,
> > 
> > 	We'd like to be able to pass algorithm-specific parameters to
> > comp backends. As of this moment, crypto usees hard-coded default
> > values and does not permit any run-time algorithm configuration,
> > which in some cases simply disables the most interesting functionality.
> > E.g. zstd can be configured to use a pre-trained (in the user-space)
> > compression dictionary, which significantly changes algorithms
> > characteristics. Another, obvious and trivial example, is algorithms
> > compression level.
> > 
> > The problem is that we need to pass params to cra_init() function,
> > because for some algorithms that's the only place where configuration
> > can take place (e.g. zstd). Changing cra_init() to accept additional
> > `struct crypto_comp_params` looks to be a little intrusive so before
> > I write any patches I'd like to hear your thoughts.
> > 
> 
> Have you considered just using the zstd library (<linux/zstd.h>) directly?

Yes, sort of.

> Which kernel subsystem are you working on that uses compression?

Forgot to mention - this is for zram primarily (and potentially for zswap).
Both of which take advantage of crypto API and can be configured to use
various compression algorithms (per-device).

So, on the zram side, in theory, I can stop using crypto API and start
calling lzo/zstd/lz4/etc. compression/decompression functions directly
(in fact we used to do that many many years ago, before we switched to
cypto API).

      reply	other threads:[~2024-04-30  3:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-30  3:04 [RFC] crypto: passing configuration parameters to comp algos Sergey Senozhatsky
2024-04-30  3:18 ` Eric Biggers
2024-04-30  3:28   ` Sergey Senozhatsky [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240430032800.GF14947@google.com \
    --to=senozhatsky@chromium.org \
    --cc=davem@davemloft.net \
    --cc=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.