On Tue, Sep 22, 2026 at 04:49:45PM +0300, Itai Handler wrote: > Storage is not the use case - crypto offload is. > > Where the cipher is a hardware engine driven over DMA, the per-request > cost is a descriptor setup and a round trip, and that cost dominates. > Making the request sixteen times larger amortises it. With the in-tree > qce driver on an arm64 64k-page board, plain dm-crypt over a ramdisk, > MB/s:
That isn't a real use case, though. Using the QCE driver is *much* slower than just using the encryption on the CPU, even on long messages. That's been established in many previous discussions and is now even admitted by the maintainers of the QCE driver. The QCE driver even (incredibly) uses more CPU time than just doing the crypto on the CPU, due to all its driver, scheduling, and IRQ overhead. The pending patches to add BAM locking will make it even slower. The fix is to not use QCE. (And also ensure that CONFIG_CRYPTO_AES_ARM64_CE_BLK=y is set, to get the ARMv8 CE accelerated code. But even on legacy CPUs without ARMv8 CE, QCE is still slower.) Unsurprisingly, the numbers in this patch's cover letter show this as well, with much higher throughput reported for the CPU-based encryption. (Also note that QCE is currently marked as BROKEN upstream.) I really do not think dm-crypt should accept changes to further accommodate obsolete and problematic external crypto engines like this. - Eric
