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