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.

Current dmaengine support xor is

Driver File		Driver Name			First Added Date
==========================================================================
mv_xor.c		Marvell XOR Engine (mv_xor)	2008-07-08
ppc4xx/adma.c		ppc440spe ADMA (PPC4xx)		2009-12-11
fsl_raid.c		Freescale RAID Engine (fsl_re)	2015-03-03
xgene-dma.c		APM X-Gene DMA			2015-03-18
ioat/init.c		Intel IOAT DMA (ioatdma)	2015-08-11
mv_xor_v2.c		Marvell XOR Engine v2		2016-06-16
bcm-sba-raid.c		BCM SBA RAID (Broadcom)		2017-05-15

fsl_raid is for power pc SoC, which already EOF.

Patches is build test only now.

To: Alasdair Kergon <agk@redhat.com>
To: Mike Snitzer <snitzer@kernel.org>
To: Mikulas Patocka <mpatocka@redhat.com>
To: Benjamin Marzinski <bmarzins@redhat.com>
To: Song Liu <song@kernel.org>
To: Yu Kuai <yukuai@fygo.io>
To: Li Nan <magiclinan@didiglobal.com>
To: Xiao Ni <xiao@kernel.org>
To: Dan Williams <djbw@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
To: "David S. Miller" <davem@davemloft.net>
To: Jonathan Corbet <corbet@lwn.net>
To: Shuah Khan <skhan@linuxfoundation.org>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: dm-devel@lists.linux.dev
Cc: linux-kernel@vger.kernel.org
Cc: linux-raid@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Saeed Bishara <saeed@marvell.com>
Cc: Rameshwar Prasad Sahu <rsahu@apm.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anup Patel <anup.patel@broadcom.com>

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Frank Li (4):
      md/dm-integrity: replace async_tx with synchronous xor for journal
      md/raid5-ppl: replace async_tx with synchronous xor
      md/raid5: replace async_tx with synchronous xor/pq operations
      crypto: remove async_tx framework

 Documentation/crypto/async-tx-api.rst | 270 ---------------
 Documentation/crypto/index.rst        |   1 -
 crypto/Kconfig                        |   5 -
 crypto/Makefile                       |   4 -
 crypto/async_tx/Kconfig               |  28 --
 crypto/async_tx/Makefile              |   7 -
 crypto/async_tx/async_memcpy.c        |  97 ------
 crypto/async_tx/async_pq.c            | 464 --------------------------
 crypto/async_tx/async_raid6_recov.c   | 595 ----------------------------------
 crypto/async_tx/async_tx.c            | 299 -----------------
 crypto/async_tx/async_xor.c           | 380 ----------------------
 crypto/async_tx/raid6test.c           | 250 --------------
 drivers/md/dm-integrity.c             |  26 +-
 drivers/md/raid5-log.h                |   4 +-
 drivers/md/raid5-ppl.c                |  40 +--
 drivers/md/raid5.c                    | 467 +++++++++++++-------------
 include/linux/async_tx.h              | 187 -----------
 17 files changed, 281 insertions(+), 2843 deletions(-)
---
base-commit: 98a4f6276df67a1bb37b1be56a3ab4285155e3df
change-id: 20261015-asycn_tx_remove-381cd003d9f7

Best regards,
--  
Frank Li <Frank.Li@nxp.com>

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