Hi.

On Mon, Aug 11, 2008 at 11:53:41AM -0700, Loc Ho ([EMAIL PROTECTED]) wrote:
> >You do not need to pass multiple pointers, but instead a multiple data.
> >You can do that via single area provided to the kernel and multiple size 
> >fields, where each 
> > one corresponds to the size of the contiguous sectors in the provided data.
> 
> [Loc Ho]
> It sounds like the solution is to format the data (parameter values, src, 
> dst) into a single buffer. This will require memory copy of the source and 
> destination data as follow:
> 1. User space formating the user space buffer that includes:
>       1a) size parameter fields (this is required regardless)
>       2b) parameter data such as IV, adata, and etc (this is required 
> regardless)
>       3c) copy the source data from application buffer into this single 
> buffer (this is extra memcpy)
> 2. Kernel operation of the single user buffer (this is required regardless)
> 3. User space copy the destination data buffer into its appropriate memory 
> pointer
>       3a) For hash, it is just the hash
>       3b) For crypto, it is the entire buffer (= to source length)
>       3c) For aead, it is the entire buffer + aead ICV
> 
> As you can see, there is two extra memcpy's. There is noticeable performance 
> on our SoC (AMCC 4xx) which memory copy is performed.

It will be buried in noise compared to crypto processing time, but you
still can try to optimize it.

> I was thinking. What do you think about passing multiple data pointer using 
> writev (vector write)? And possible a similar idea for AIO.

Yes, that's a good approach.

Another one is to use a dedicated syscall.
It is up to you as developer decide, since all of them have advantages.

-- 
        Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to