Re: [PATCH v6 2/8] crypto: add driver-side scomp interface

[Giovanni Cabiddu <giovanni.cabiddu@intel.com>]

On Mon, Jun 13, 2016 at 04:56:12PM +0800, Herbert Xu wrote:
> The backup path is also very unlikely to work because we'll be
> hitting this with 64K sizes and this just won't work with a 4K
> page size.
Is scatterwalk_map_and_copy broken?

> So up until now we've getting around this 64K issue with vmalloc,
> and then we try to conserve the precious vmalloc resource by using
> per-cpu allocation.
I don't clearly understand what is the issue.
Can you please give me more details?

> This totally breaks down once you go to DMA, where an SG list is
> required. 
scomp backends should be used only for software implementations. 
A driver backend which needs DMA should plug into acomp.

> Unfortunately, this means that there is no easy way
> to linearise the data for our software implementations.
> 
> There is no easy way out I'm afraid.  I think we'll have to bite
> the bullet and refit our software algos so that they handle SG
> lists.
Although feasible, I think it wouldn't be an easy job.

> Not only will this solve the problem at hand, it'll also mean that
> acomp users will never have to do vmalloc so it's a win-win.  It
> also means that we won't need the scomp interface at all.
> 
> This does bring up another question of who should be allocating the
> output memory.  Up until now it has been up to the user to do so.
> However, if our algos can actually handle SG lists then I think it
> should be fairly easy to make them do the allocation instead.  What
> do you think?
I would prefer the user of the api to allocate and manage the output
memory.

Thanks,

-- 
Giovanni