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

[David Sterba <dsterba@suse.cz>]

On Wed, May 07, 2025 at 09:19:14PM -0700, Eric Biggers wrote:
> 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.

Ok, so on hand the recommendation is to use an obscure tool and
interface and ont the other hand kernel is moving towards library API.
I don't mind using the library approach, as long as it provides the
automatic selection of the fastest implementation available (it could be
even an extra API call e.g. at mount time).

> 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.

No problem with that. I once had a prototype to do async checksumming
and using the ahash was indeed cumbersome, with the mempools and request
handling to avoid deadlocks.

> 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.

As along as the switch to library or QAT can be in a wrapper I don't
mind.

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

I think the plan is to support zstd as well but the QAT integration
should be simpler on zlib. I'd like to see some up to date code first to
get better idea of what and how.