Re: [RFC PATCH 00/16] btrfs: offload compression to hardware accelerators

[Christoph Hellwig <hch@infradead.org>]

On Wed, Dec 03, 2025 at 07:47:11PM +0900, Simon Richter wrote:
> Unpacking is quite a bit faster as well, to the point where unpacking the
> compressed block of 4GiB NUL bytes is faster than reading 4 GiB from
> /dev/zero for me.

Which makes me wonder why Intel isn't showing decompression numbers.
For file system workloads those generally are more much common, and
they are generally synchronous while writes often or not, and
compressible ones should be even less so.

> For acomp, I pretty much always expect offloading to be worth the overhead
> if hardware is available, simply because working with bitstreams is awkward
> on any architecture that isn't specifically designed for it, and when an
> algorithm requires building a dictionary, gathering statistics and two-pass
> processing, that becomes even more visible.

I would be really surprised if it makes sense for just a few kilobyes,
e.g. a single compressible btrfs extent.  I'd love to see numbers
proving me wrong, though.

> For ahash/acrypt, there is a trade-off here, and where it is depends on CPU
> features, the overhead of offloading, the overhead of receiving the result,
> and how much of that overhead can be mitigated by submitting a batch of
> operations.
>
> For the latter, we also need a better submission interface that actually
> allows large batches, and submitters to use that.

For acrypt Eric has shown pretty devastating numbers for offloads.  Which
doesn't surprise me at all given how well modern CPUs handle the
low-level building blocks for cryptographic algorithms.

> As an example of interface pain points: ahash has synchronous import/export
> functions, and no way for the driver to indicate that the result buffer must
> be reachable by DMA as well, so even with a mailbox interface that allows me
> to submit operations with low overhead, I need to synthesize state readbacks
> into an auxiliary buffer and request an interrupt to be delivered after each
> "update" operation, simply so I can have the state available in case it is
> requested, while normally I would only generate an interrupt after an
> "export" or "final" operation is completed (and also rate-limit these).

Which brings me to my previous point:  ahash from the looks off it
just looks like a pretty horrible interface.  So someone really needs
to come up with an easy to use interface that covers to hardware and
software needs.  Note that on the software side offloading to multiple
other CPU core would be a natural fit and make it look a lot like an
async hardware offload.   You'd need to make it use the correct data
structures, e.g. bio_vecs provided for source and destination instead
of scatterlist, and clear definitions of addressability.  Bounce points
for supporting PCIe P2P transfers, which seems like a very natural fit
here.