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
