Re: [PATCH RFC 0/4] async_tx/md: Remove async_tx framework

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Oct 15, 2026 at 03:22:24PM -0400, Frank.Li@oss.nxp.com wrote:
> This RFC is collecting more feedbacks to device when is good time to remove
> whole async_tx framework and how to remove it safely. And is overall
> direction correction.
> 
> Little to no real hardware acceleration usage:
>   Most systems run RAID5/6 parity calculations on the CPU using optimized
>   XOR/PQ implementations, while DMAEngine-backed async_tx acceleration is
>   rarely present or exercised.
> 
> Added abstraction and maintenance cost:
>   async_tx introduces an extra layer between MD RAID and parity operations,
>   making the code harder to understand, debug, and maintain.
> 
> Modern CPUs outperform DMA offload:
>   SIMD implementations (SSE/AVX/NEON and architecture-specific RAID
>   routines) often provide better performance than DMA descriptor setup and
>   completion handling overhead.
> 
> Obsolete hardware dependencies:
>   Many async_tx acceleration backends were designed for older DMA/XOR
>   engines that are no longer common in contemporary systems.
> 
> Complex asynchronous execution model:
>   Dependency chains, callback handling, and DMA transaction management
>   increase code complexity without corresponding performance benefits on
>   typical deployments.Simplifies RAID code paths: Removing async_tx allows
>   direct use of synchronous XOR/PQ helpers, reducing indirection in raid5.c
>   source code [linux/drivers/md/raid5.c].
> 
> Reduces testing burden:
>   Eliminates rarely used code paths that are difficult to validate and more
>   likely to accumulate latent bugs.
> 
> Aligns implementation with actual usage:
>   The vast majority of MD RAID deployments already rely on software parity
>   generation rather than DMA offload.
[..]
>  17 files changed, 281 insertions(+), 2843 deletions(-)

I haven't been paying much attention to the crypto/async_tx/ directory,
but this makes sense to me.  This mirrors similar trends that we've seen
with the crypto and CRC algorithms.  For these types of algorithms, just
using the CPU is faster and much simpler than trying to offload the
operation to some external hardware engine (which rarely even exist).

- Eric