Re: [RFC PATCH 6/6] btrfs: zlib: add support for zlib-deflate through acomp

[Eric Biggers <ebiggers@kernel.org>]

On Wed, May 07, 2025 at 02:17:54PM +0200, David Sterba wrote:
> 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.

I don't think there ever will be.  NETLINK_CRYPTO is obscure and hardly anyone
uses it.  The kernel's generic crypto infrastructure is also really cumbersome
to use, so the trend in the kernel overall has been a move away from the generic
crypto infrastructure and towards straightforward library APIs (e.g.
lib/crypto/) that just do the right thing with no configuration needed.

btrfs already uses the compression library APIs.  Considering how disastrous
crypto_acomp has been so far when other people tried to use it, most likely the
right decision will be to keep using the library APIs for the vast majority of
btrfs users, and have an alternative code path that uses crypto_acomp only when
hardware offload is actually being used.

There may also be a way to rework things so that the compression library APIs
can use hardware offload, in which case the crypto API would play no role at
all.  I understand the Zstandard library in userspace can use Intel QAT as an
external sequence provider, so it's been proven that this can be done.

BTW, I also have to wonder why this patchset is proposing accelerating zlib
instead of Zstandard.  Zstandard is a much more modern algorithm.

- Eric