Communications kernel -> userland

[Robert Watson]

On Mon, 21 Jul 2003, Pawel Jakub Dawidek wrote:

> For example syscall is marking some range with mark() function.  For now
> on this range isn't accessable from userland. If process will try to
> write to this page, page is copied (copy-on-write).  If this page will
> be modified by kernel it will be marked as MODIFIED.  Now when syscall
> will call unmark() on this range we could get two scenarious: 
> 
> 	1. Page is marked as MODIFIED (by kernel) so userland copy
> 	   of this page (if it exists of course) is destroyed and
> 	   this page will be putted in its place.
> 	   This is replacement for copyin() and then copyout() or
> 	   just copyout()..
> 	2. Page isn't marked as MODIFIED, so kernel version of page
> 	   is destroyed (is there is userland version).
> 	   This is replacement for just copyin().
> 
> There could be other ways. Thread/process could be locked if it is
> trying to access memory marked with mark() function. And this, I think,
> don't hit performance, because this happends really rarely. So maybe it
> is better to lock thread for a moment instead of doplicating page, but I
> don't think so. 

This sounds a bit like some of the IO Lite stuff -- moving to a
page-centric model for IO interfaces to avoid copy operations, in many
cases able to share pages between applications, buffer cache, network
buffers, etc. Take a look at:

  http://www.cs.princeton.edu/~vivek/

For some details.  Some of the benefits of this approach are captured in
the common case through sendfile(), in practice, but it's definitely worth
a read.

I guess what I had in mind was something more network-specific, with
interfaces optimized for memory mapped network packet streams.  In the
simplest case, something like memory-mapping the BPF buffer from kernel
space to userspace, with some sort of simple stream synchronization so
that the user application could notify the kernel as to when it could
reuse bits of the buffer, but avoiding copy operations and lots of context
switching. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Network Associates Laboratories