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

[David Sterba <dsterba@suse.cz>]

On Fri, Nov 28, 2025 at 10:40:33PM +0000, Giovanni Cabiddu wrote:
> On Sat, Nov 29, 2025 at 08:25:30AM +1030, Qu Wenruo wrote:
> > 在 2025/11/29 05:35, Giovanni Cabiddu 写道:
> > > Add support for hardware-accelerated compression using the acomp API in
> > > the crypto framework, enabling offload of zlib and zstd compression to
> > > hardware accelerators. Hardware offload reduces CPU load during
> > > compression, improving performance.
> > > 
> > > The implementation follows a generic design that works with any acomp
> > > implementation, though this enablement targets Intel QAT devices
> > > (similarly to what done in EROFS).
> > > 
> > > Input folios are organized into a scatter-gather list and submitted to
> > > the accelerator in a single asynchronous request. The calling thread
> > > sleeps while the hardware performs compression, freeing the CPU for
> > > other tasks.  Upon completion, the acomp callback wakes the thread to
> > > continue processing.
> > > 
> > > Offload is supported for:
> > >    - zlib: compression and decompression
> > >    - zstd: compression only
> > > 
> > > Offload is only attempted when the data size exceeds a minimum threshold,
> > > ensuring that small operations remain efficient by avoiding hardware setup
> > > overhead. All required buffers are pre-allocated in the workspace to
> > > eliminate allocations in the data path.
> > > 
> > > This feature maintains full compatibility with the existing BTRFS disk
> > > format. Files compressed by hardware can be decompressed by software
> > > implementations and vice versa.
> > > 
> > > The feature is wrapped in CONFIG_BTRFS_EXPERIMENTAL and can be enabled
> > > at runtime via the sysfs parameter /sys/fs/btrfs/<UUID>/offload_compress.
> > 
> > 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?

At least for the duration of the experimental phase the sysfs is the
right interface for enabing/disabling the QAT support.

In the long term I'd still recommend sysfs, this is easily accessible by
scripts unlike alternative way of ioctl. I don't know about other
reasonable options for that, certainly not a mount option.