Re: [PATCH v6 0/6] crypto: skcipher - multi-data-unit request splitting

[Christoph Hellwig <hch@infradead.org>]

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.