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

[Herbert Xu <herbert@gondor.apana.org.au>]

On Thu, Sep 22, 2016 at 11:54:25PM +0100, Giovanni Cabiddu wrote:
> > 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.
> Why would you prefer to have the output buffer allocated in the acomp
> layer? Is there a use case for this? Who would free that memory?

When I said acomp layer I'm referring specifically to the algorithm
or driver.  As to your last question it would be the caller's
responsibility to free that memory.

The use-case is our oldest user, IPcomp.  Most packets are 1500 bytes
max but we have to allocate 64K of memory to cover the worst case.
For an algorithm that can deal with SG lists it can easily allocate
pages of memory as it goes and place them in an SG list.

> We believe that the output buffer should be allocated by the user of the
> API. A caller might decide to allocate memory upfront or point the
> buffer list to pre-allocate buffers. This would happen in BTRFS where
> its block buffers are already allocated for submission to the
> compression API.

Sure if you already have memory allocated then we don't want to
force you to allocate it again in the algorithm/driver.  But our
interface should allow the memory to be allocated in the driver.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt