summaryrefslogtreecommitdiffstats
path: root/share/man/man4/bpf.4
diff options
context:
space:
mode:
authorrwatson <rwatson@FreeBSD.org>2008-04-07 02:51:00 +0000
committerrwatson <rwatson@FreeBSD.org>2008-04-07 02:51:00 +0000
commit6d3db5778b32c179b5499f160873c71457fb1a56 (patch)
tree22f480af437b5929bf51d1bf686a1ec51d4fd260 /share/man/man4/bpf.4
parentd566093a4035dd7af0c40607a130aa52bfb4e301 (diff)
downloadFreeBSD-src-6d3db5778b32c179b5499f160873c71457fb1a56.zip
FreeBSD-src-6d3db5778b32c179b5499f160873c71457fb1a56.tar.gz
Maintain and observe a ZBUF_FLAG_IMMUTABLE flag on zero-copy BPF
buffer kernel descriptors, which is used to allow the buffer currently in the BPF "store" position to be assigned to userspace when it fills, even if userspace hasn't acknowledged the buffer in the "hold" position yet. To implement this, notify the buffer model when a buffer becomes full, and check that the store buffer is writable, not just for it being full, before trying to append new packet data. Shared memory buffers will be assigned to userspace at most once per fill, be it in the store or in the hold position. This removes the restriction that at most one shared memory can by owned by userspace, reducing the chances that userspace will need to call select() after acknowledging one buffer in order to wait for the next buffer when under high load. This more fully realizes the goal of zero system calls in order to process a high-speed packet stream from BPF. Update bpf.4 to reflect that both buffers may be owned by userspace at once; caution against assuming this.
Diffstat (limited to 'share/man/man4/bpf.4')
-rw-r--r--share/man/man4/bpf.416
1 files changed, 8 insertions, 8 deletions
diff --git a/share/man/man4/bpf.4 b/share/man/man4/bpf.4
index 9116b2d..39e1399 100644
--- a/share/man/man4/bpf.4
+++ b/share/man/man4/bpf.4
@@ -259,14 +259,14 @@ may be used to sleep awaiting the availbility of a completed buffer.
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
OpenPOWER on IntegriCloud