Thread (5 messages) flat view 5 messages, 2 authors, 2016-09-27

Re: [PATCH v7 4/9] crypto: acomp - add support for lzo via scomp

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2016-09-22 09:23:48

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:
quoted
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
time.
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.

Cheers,
-- 
Email: Herbert Xu [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help