On Fri, Aug 23, 2002 at 08:38:35AM -0700, Jason R Thorpe wrote:
> On Fri, Aug 23, 2002 at 08:12:34AM -0600, kyle.unice@L-3com.com wrote:
> 
>  > The salient point is that copying memory from one buffer to another will
>  > always take longer than passing a pointer.  The larger the amount of memory
> 
> That is *not* always true.

Agreed.  I make a significant performance IMPROVEMENT to an fddi
driver by ADDING a data copy in both the transmit and receive paths.
Basically the code required to handle the 'buffer loaning' actually
cost more than the data copy.
> 
> In a virtual memory system, "passing a pointer" across a protection boundary
> involves changing mappings, which potentially means cache flushing and TLB
> invalidation traffic.  The latter can potentially be expensive on a multi-
> processor.

And on some architectures (eg sbus suns) where mmu mappings have to
be set up betwen the io device and physical memory.
> 
> For small amounts of data, and even moderate amounts of data, a copy may
> in fact be faster than remapping the data.

IIRC it is possible to get some cache controllers to do cache-line
aligned copies for you.  For processors with a memory move instruction
(eg x86) the designers can (and probably do) throw some silicon at
that instruction so that it is executed in the 'appropriate' part
of the system.  Even the humble 386 executes rep movs faster than
rep lods or rep stos.

> 
> Now, you talk about VxWorks being ring0 only... THAT would be analogous
> to an application running entirely in the NetBSD kernel.  In that case,
> NetBSD *already* has the zero-copy semantics I described before (with
> the exception of how data is compacted in the socket buffer ... but that
> is certainly something that can be tuned, and it only does the compaction
> for small amounts of data anyway).

Is it possible (without a massive rewrite) to get a kernel function
called to process data that arrives on a socket?
nfs would certainly benefit from such a call.

	David

-- 
David Laight: david@l8s.co.uk