PERFORCE change 131579 for review

[Robert Watson]

http://perforce.freebsd.org/chv.cgi?CH=131579

Change 131579 by rwatson at rwatson_cinnamon on 2007/12/25 11:57:13

	Annotate a somewhat subtle problem associated with using purely
	asynchronous acknowledgements that userspace has finished with a
	buffer.  We currently allow only one buffer to be owned by userspace
	at a time, and there is a scenario in which the fact that
	acknowledging a buffer from userspace won't force the kernel to
	rotate the buffers, just the arrival of a next packet, which might
	never happen.  I have a possible solution for this but need to think
	more about the implications of it.

Affected files ...

.. //depot/projects/zcopybpf/README#4 edit

Differences ...

==== //depot/projects/zcopybpf/README#4 (text+ko) ====

@@ -52,3 +52,29 @@
 If doing an incremental rebuild of libpcap, make sure to "make clean" before
 "make" and "make install", as the dependencies appear not always to pick up
 changes in the size of pcap_t, which can cause libpcap to become confused.
+
+Issues
+------
+
+The zero-copy buffer implementation follows the same held/store/free buffer
+model as with buffered reads.  We currently assign ownership of a buffer to
+userspace using the user/kernel generation number scheme only for buffers in
+the store position.  As the user acknowledgement to the kernel is
+asynchronous (via a memory write rather than a system call), it's possible to
+get into a state where the a rotation won't occur until another packet is
+delivered to BPF, even if the buffer in the store spot is full.  This means
+that the user process may wait undefinitely for the store buffer to be move
+to the hold position and get assigned to userspace, if no new packets arrive.
+This should probably be fixed by allowing a full buffer in the store spot to
+be assigned to userspace, allowing the buffer to be fully read without
+waiting for a new packet to arrive in order to trigger the state machine.
+
+This can be worked around in userspace by performing a rotate ioctl to cause
+the recently acknowledge buffer to be moved into the free position (etc)
+before sleeping waiting for new data (libpcap currently doesn't do this), but
+this problem should be fixed properly by modifying the buffer model.  This is
+slightly undesirable as it offers different buffer semantics than with
+buffered reads, and will require the BPF code to know that sometimes it isn't
+allow to write packet data to the store buffer even if there is room (as a
+larger previous packet may have caused ownership to be assigned to userspace,
+meaning that the kernel can no longer write to the buffer).