I really don't understand. Why are using a NetBSD mailing list to
discuss the poor quality-of-implementation of Linux packet-capture
tools?  The decidely weak paper that SMB cited does a lousy job of
using bpf (by the standards of published prior art) using bpf, yet
even so it's still quite competitive.


My local datapoint: with bge drivers tuned for low latency (high
ihterrupt load), running in a P4 Xeon 3.06Ghz under test, I can
approximate the rate of an (untuned) fxp driver. I have only one
client handy to run the stream ACK-DoS tool, but I can trivially hit
an input rate of 160k packets/sec and 80k interrupts/sec.  After
enabling interrupt deferral, the exact same "DoS" [sic] traffic load
yields under 3k interrupts/sec -- at a point where heavily-buffered
bpf can keep up fine, thanks.

Here's the tcpdump exit stats after 10 seconds at 160k packets/sec,
(the rate quoted for the sunfire experiments)

	2547185 packets received by filter
	0 packets dropped by kernel

(I think that's with a default 4k bpf bufsize; certainly no more than
512k, which is the kernel limit. I dont _think_ I patched tcpdump on
this machien to up the limit, but I could have forgotten).

Oh, and Fig. 1 of the cited paper has no scale, and no indicated datapoints.