Skip site navigation (1)Skip section navigation (2)
Date:      Sun,  3 Dec 2000 22:49:44 -0500 (EST)
From:      Andrew Gallatin <gallatin@cs.duke.edu>
To:        Peter Wemm <peter@netplex.com.au>
Cc:        "Kenneth D. Merry" <ken@kdm.org>, arch@FreeBSD.ORG, dillon@FreeBSD.ORG
Subject:   Re: zero copy code review 
Message-ID:  <14891.4047.626648.658103@grasshopper.cs.duke.edu>
In-Reply-To: <200012040308.eB438tD52326@mobile.wemm.org>
References:  <20001129231653.A1503@panzer.kdm.org> <200012040308.eB438tD52326@mobile.wemm.org>

next in thread | previous in thread | raw e-mail | index | archive | help

Peter Wemm writes:
<...>
 > Hmm.. I see one danger item:

<..>

 > [..]
 >               Turn on vfs.ioopt to enable zero copy receive: 
 >                sysctl -w vfs.ioopt=1
 > "

This was a convenient sysctl to tie the zero-copy receive code to in
early prototyping.  It has nothing to do with the filesystem aspects
of vfs_ioopt, which makes it confusing to the reader.  This should
probably be ripped out or changed to depend only on the zero-copy
sockets sysctl.

Rather than loaning out pages, the zero-copy receive code does full
page-flipping, mapping the kernel's page into the receiving process
and freeing the page the user process was receiving into.  This is
possible because, unlike pages in the buffer cache, there is no need
to keep around data received on a socket.

<... objections to vfs_ioopt deleted...>

 > I have not read the patch extensively, but I am not sure that it is handled
 > completely.  There are a few patches to vm_fault(), but I am not sure if
 > these are to handle the problem I described above or something else.  In
 > particular, if it is intended to handle the problem, then it seems to depend
 > on being able to make pages unwritable by the kernel.  This isn't possible
 > on i386 cpus (only 486 and later).  I did not see any busmaster DMA checking

The patches are to support making pages sent via zero-copy sockets COW
for the user process which sent them (until they are acknowledged and
freed).  We do not make anything COW for the kernel.

 > either, but I could have missed it..  What about drivers that DMA to pages
 > mapped into KVM without checking writability (and hence COW)?  

This is a good point.  But I cannot think of any circumstance where a
driver would be DMA'ing directly to a user owned page (with the
exception of a vm fault, but this is impossible because the pages are
resident prior to setting up the send and are wired for the duration
of the send).

Thanks for the input.  I'm glad to see you and Matt looking at this!

Drew


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14891.4047.626648.658103>