Re: [RFC PATCH 16/16] btrfs: add compression hw-accelerated offload

[David Sterba <dsterba@suse.cz>]

On Sat, Nov 29, 2025 at 10:29:04AM +1030, Qu Wenruo wrote:
> 
> 
> 在 2025/11/29 09:10, Giovanni Cabiddu 写道:
> > Thanks for your feedback, Qu Wenruo.
> > 
> > On Sat, Nov 29, 2025 at 08:25:30AM +1030, Qu Wenruo wrote:
> [...]
> >> Not an compression/crypto expert, thus just comment on the btrfs part.
> >>
> >> sysfs is not a good long-term solution. Since it's already behind
> >> experiemental flags, you can just enable it unconditionally (with proper
> >> checks of-course).
> > The reason for introducing a sysfs attribute is to allow disabling the
> > feature to be able to unload the QAT driver or to assign a QAT device to
> > user space for example to QATlib or DPDK.
> > 
> > In the initial implementation, there was no sysfs switch because the
> > acomp tfm was allocated in the data path. With the current design,
> > where the tfm is allocated in the workspace, the driver remains
> > permanently in use.
> > 
> > Is there any other alternative to a sysfs attribute to dynamically
> > enable/disable this feature?
> 
> For all needed compression algorithm modules are loaded at btrfs module 
> load time (not mount time), thus I was expecting the driver being there 
> until the btrfs module is removed from kernel.
> 
> This is a completely new use case. Have no good idea on this at all. 
> Never expected an accelerated algorithm would even get removed halfway.
> 
> [...]
> >>
> >> This function get all input/output folios in a batch, but ubifs, which also
> >> uses acomp for compression, seems to only compress one page one time
> >> (ubifs_compress_folio()).
> >>
> >> I'm wondering what's preventing us from doing the existing folio-by-folio
> >> compression.
> >> Is the batch folio acquiring just for performance or something else?
> > There are a few reasons for using batch folio processing instead of
> > folio-by-folio compression:
> > 
> > * Performance: for a hardware accelerator like QAT, it is more efficient to
> >    process a larger chunk of data in a single request rather than issuing
> >    multiple small requests. (BTW, it would be even better if we could batch
> >    multiple requests and run them asynchronously!)
> > 
> > * API limitations: The current acomp interface is stateless. Supporting
> >    folio-by-folio compression with proper streaming would require changes
> >    to introduce a stateful API.
> 
> BTW, is there any extra benefit of using acomp interface (independent of 
> QAT acceleration)?

The promise of the acomp interface is that the CPU can be handed to
other processes while the async hw does the compression. Using the async
requests has some problems with deadlocks and allocation. The async
crypto API has been deprecated or removed where used, IIRC fsverity.

> If so we may consider experiment with it first and migrate btrfs to that 
> interface step by step, and making extra accelerated algorithms easier 
> to implement.

I had a prototype for acomp and switching to it via sysfs but once I
saw the patches removing acomp I scrapped it. The QAT is a bit different
as it's extensible, the acomp hw engines I assume the interface was made
for were hw cards and accelerators that eg. implemented zlib. With QAT
we can have LZO, ZSTD so it's worth adding the support.