In message <20040123194559.92054.qmail@web41211.mail.yahoo.com>,
Gary Thorpe writes:

>Hi,
>
>I just have a question: why is there so much _resistance_ to the
>possibility that you might actually improve BPF's performance by
>changing the implementation to use a ring buffer?

Huh? Scuse me, but where did that come from?

I have no real resistance to adding a ringbuffer API to BPF, provided
experiment shows its acutally worthwhile -- when compared to bpf with
buffer sizes consonant with widely-known ``best-practice'', as we
have now.  I careful to say that, two or three different times.

The point is more that the default FreeBSD buffer sizes (plus polling)
are within 3% of the Linux ringbuffer sizes. I've just increased the
sizes dramaticaly (six compound doublings, sysctl'able to two more
with no change to libpcap).  We __know__ that increasing the bpf
buffers that much yields a dramatic decrease in drop rates.

At this point, we're much better off purusing interrupt mitigation
(which benefits all receive-side NIC traffic, not just bpf).

Then we can re-measure drop rates, and see if there's any reason to do
a ring-buffer.  Even the default FreeBSD capture size is within a last
3% or so. With the much larger buffer sin -current, I'd expect that
the benfits from a ring-buffer will be very small, on all but the most
chronically memory-bandwith-limited machines.