Date: Tue, 25 Mar 2008 09:14:36 GMT From: Robert Watson <rwatson@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 138505 for review Message-ID: <200803250914.m2P9EaKo024086@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=138505 Change 138505 by rwatson@rwatson_cinnamon on 2008/03/25 09:14:08 Update bpf.4 to reflect that both buffers may be owned by userspace at once; caution against assuming this. Affected files ... .. //depot/projects/zcopybpf/src/share/man/man4/bpf.4#12 edit Differences ... ==== //depot/projects/zcopybpf/src/share/man/man4/bpf.4#12 (text+ko) ==== @@ -259,14 +259,14 @@ They will return a readable file descriptor when ownership of the next buffer is assigned to user space. .Pp -In the current implementation, the kernel will assign ownership of at most -one buffer at a time to the user process. -The user processes must acknowledge the current buffer in order to be -notified that the next buffer is ready for processing. -Programs should not rely on this as an invariant, as it may change in future -versions; in particular, they must maintain their own notion of which buffer -is "next" so that if both buffers are owned by userspace, it can process them -in the correct order. +In the current implementation, the kernel may assign zero, one, or both +buffers to the user process; however, an earlier implementation maintained +the invariant that at most one buffer could be assigned to the user process +at a time. +In order to both ensure progress and high performance, user processes should +acknowledge a completely processed buffer as quickly as possible, returning +it for reuse, and not block waiting on a second buffer while holding another +buffer. .Sh IOCTLS The .Xr ioctl 2
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200803250914.m2P9EaKo024086>