Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure support

[Tim Chen <tim.c.chen@linux.intel.com>]

On Tue, 2015-11-17 at 21:06 +0800, Herbert Xu wrote:
> On Thu, Oct 29, 2015 at 03:21:03PM -0700, Tim Chen wrote:
> > 
> > c) Add support to crypto scatterwalk support that can sleep during
> > encryption operation, as we may have buffers for jobs in data lanes
> > that are half-finished, waiting for additional jobs to come to fill
> > empty lanes before we start the encryption again.  Therefore, we need to
> > enhance crypto walk with the option to map data buffers non-atomically.
> > This is done by algorithms run from crypto daemon who knows it is safe
> > to do so as it can save and restore FPU state in correct context.
> 
> What about the existing ablkcipher scatterwalk helpers?
> 
> Cheers,

I suppose blkcipher was originally used because we 
were under the impression that there are less buffer copying
and less allocation of intermediate buffers
with blkcipher walk. 

But looking at the blkcipher walk and ablkcipher
walk code more carefully now, I am not sure that's really true
as it seems like ablkcipher keep all intermediate buffers till the
end and copy them to destination in one shot while blkcipher does
that at walk of every chunk.  The advantage of blkcipher is
you don't have as many outstanding buffers in a list.  If there's
really not much speed difference, I can try to use ablkcipher.

Herbert, would you prefer me to use ablkcipher scatter walk instead,
assuming the overhead of both walk are about the same?

Thanks.

Tim