From: David Sterba <dsterba@suse.cz>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "Cabiddu, Giovanni" <giovanni.cabiddu@intel.com>,
Josef Bacik <josef@toxicpanda.com>, "clm@fb.com" <clm@fb.com>,
"dsterba@suse.com" <dsterba@suse.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
qat-linux <qat-linux@intel.com>, "embg@meta.com" <embg@meta.com>,
"Collet, Yann" <cyan@meta.com>,
"Will, Brian" <brian.will@intel.com>,
"Li, Weigang" <weigang.li@intel.com>
Subject: Re: [RFC PATCH 6/6] btrfs: zlib: add support for zlib-deflate through acomp
Date: Wed, 7 May 2025 14:17:54 +0200 [thread overview]
Message-ID: <20250507121754.GE9140@suse.cz> (raw)
In-Reply-To: <aBrEOXWy8ldv93Ym@gondor.apana.org.au>
On Wed, May 07, 2025 at 10:23:53AM +0800, Herbert Xu wrote:
> On Tue, May 06, 2025 at 04:38:11PM +0100, Cabiddu, Giovanni wrote:
> >
> > > We'd have to enhance the compression format specifier to make it
> > > configurable in the sense: if accelerator is available use it, otherwise
> > > do CPU and synchronous compression.
> > For usability, wouldn't it be better to have a transparent solution? If
> > an accelerator is present, use it, rather than having a configuration
> > knob.
>
> If you go through the Crypto API you won't need to add a new knob
> at all.
>
> The Crypto API is already configurable and comes with a knob
> pre-installed. Just download crconf and you can configure which
> algorithm will be used by default:
>
> https://git.code.sf.net/p/crconf/code
First time I hear about such tool and given what it does I think it
should have better visibility and presence also in "the other" git
sources. It's not mentioned in linux Documentation either.
SourceForge is not taken seriously for quite some time and the project
landing page https://sourceforge.net/projects/crconf/ matches the
pattern of abandoned SF projects, last commit 5 years ago.
The first hit on gihub is https://github.com/Thermi/crconf and at least
it matches the SF commits.
The command line interface follows the iproute2 style that is
arguably hard to navigate:
$ ./crconf
Usage: crconf add { ALG | DRIVER } TYPE [ PRIORITY ]
crconf del DRIVER TYPE
crconf update DRIVER TYPE [ PRIORITY ]
crconf show { DRIVER TYPE | all }
crconf help
ALG := alg <alg-name>
DRIVER := driver <driver-name>
TYPE := type ALGO-TYPE
PRIORITY := priority <number>
ALGO-TYPE := { 1 | 2 | 3 | 5 | 8 | 10 | 11 | 12 | 13 | 14 | 15 }
1 == alg type cipher
2 == alg type compress
3 == alg type aead
5 == alg type skcipher
8 == alg type kpp
10 == alg type acompress
11 == alg type scompress
12 == alg type rng
13 == alg type akcipher
14 == alg type hash
14 == alg type shash
15 == alg type ahash
The manual page lacks any useful examples and figuring out how to set
the priority took me a few minutes of grepping in /proc/crypto, trial
and error to end up with:
sudo ./crconf update driver sha256-generic type 14 priority 1000
The usability has a lot of room for improvement.
Anyway, assuming there will be a maintained, packaged in distros and
user friendly tool to tweak the linux crypto subsystem I agree we don't
have to do it in the filesystem or other subsystems.
next prev parent reply other threads:[~2025-05-07 12:18 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 10:54 [RFC PATCH 0/6] btrfs: offload zlib-deflate to accelerators Giovanni Cabiddu
2024-04-26 10:54 ` [RFC PATCH 1/6] Revert "crypto: testmgr - Remove zlib-deflate" Giovanni Cabiddu
2024-04-26 10:54 ` [RFC PATCH 2/6] Revert "crypto: deflate " Giovanni Cabiddu
2024-04-26 10:54 ` [RFC PATCH 3/6] Revert "crypto: qat " Giovanni Cabiddu
2024-04-26 10:54 ` [RFC PATCH 4/6] Revert "crypto: qat - remove unused macros in qat_comp_alg.c" Giovanni Cabiddu
2024-04-26 10:54 ` [RFC PATCH 5/6] crypto: qat - change compressor settings for QAT GEN4 Giovanni Cabiddu
2024-04-26 10:54 ` [RFC PATCH 6/6] btrfs: zlib: add support for zlib-deflate through acomp Giovanni Cabiddu
2024-04-29 13:56 ` Josef Bacik
2024-04-29 15:21 ` Cabiddu, Giovanni
2024-04-29 15:44 ` David Sterba
2024-05-03 10:04 ` Herbert Xu
2024-04-29 15:41 ` David Sterba
2025-05-06 15:38 ` Cabiddu, Giovanni
2025-05-07 2:23 ` Herbert Xu
2025-05-07 12:17 ` David Sterba [this message]
2025-05-08 4:19 ` Eric Biggers
2025-05-12 17:52 ` David Sterba
2025-05-27 2:32 ` Gao Xiang
2025-05-27 2:45 ` Gao Xiang
2025-05-27 11:17 ` David Sterba
2025-05-27 12:08 ` Gao Xiang
2025-05-07 12:43 ` David Sterba
2025-05-07 13:12 ` Cabiddu, Giovanni
2024-04-29 15:57 ` David Sterba
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=20250507121754.GE9140@suse.cz \
--to=dsterba@suse.cz \
--cc=brian.will@intel.com \
--cc=clm@fb.com \
--cc=cyan@meta.com \
--cc=dsterba@suse.com \
--cc=embg@meta.com \
--cc=giovanni.cabiddu@intel.com \
--cc=herbert@gondor.apana.org.au \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=qat-linux@intel.com \
--cc=weigang.li@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox