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 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 <herbert@xxxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
