On Sun, Sep 27, 2026 at 07:14:14AM +0000, Leonid Ravich wrote: > On Fri, Sep 25, 2026 at 02:10:47AM -0700, Christoph Hellwig wrote: > > On Thu, Sep 24, 2026 at 07:58:40AM +0000, Leonid Ravich wrote: > > > * No throughput *win* is claimed for software AES. The win is for > > > accelerators that amortise setup across units; the software split > > > exists so the interface works on every existing skcipher today and > > > goes quiet as algorithms gain CRYPTO_ALG_REQ_SEG. > > > > So what is the use case? So far all crypto driver we've seen have > > shown to be slower than cpu. Which one are you using that isn't? > > The engine we use is out of tree, but it is not a special case. It
It is. Without you having an upstream stack this is a complete no-go to start with. > is an SoC-integrated, DMA-driven, asynchronous xts(aes) engine of the > same class as caam, ccree, qce, hisilicon sec2, inside-secure and the > Marvell CPT drivers already in the tree. Pretty much all of them are broken as f***k everytime someone tried to use them. > For a DMA engine the scatterlist is not overhead: it is what the > hardware consumes. The per-sector cost it pays is the per-request > cost, and unit_size is what removes it. Yes, it is. Take a look how the scatterlist duplicates information already handled by the upper layers. We've been through is a lot and are moving to the dma_iova_ API because of that.
