On Tue, Sep 20, 2016 at 12:51:40PM +0100, Giovanni Cabiddu wrote:
> Hi Herbert,
> On Tue, Sep 20, 2016 at 05:26:18PM +0800, Herbert Xu wrote:
> > Rather than duplicating the scratch buffer handling in every scomp
> > algorithm, let's centralize this and put it into scomp.c.
> Are you suggesting to hide the scratch buffers from the scomp implementations
> and allocate them inside crypto_register_scomp?
I'm suggesting that we have just one set of buffers for all scomp
algorithms. After all, a CPU can only process one request at a
> Does that mean we have to go back to a scomp_alg with a flat buffer API
> and linearize inside scomp?
Yes scomp should just be flat. A sync algorithm capable of producing
partial output should use the acomp interface.
> If we take this direction, how do we support DMA from scomp implementation?
> Scratch buffers are allocated using vmalloc.
Huh? If you're doing DMA then you'd be using the acomp interface,
how can you even get into scomp?
I think you may have misread my earlier message from June. What
I'd like to see is for the acomp layer to allocate the output
memory, rather than have it provided by the user as is the case
with the current interface. The user could provide a maximum to
prevent crazy cases consuming unlimited memory.
What will happen with scomp is that it will simply use a linear
vmalloc buffer to store the output before copying it into an SG
list of individual pages allocated on the spot.
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html