Subject: Re: packet capturing
To: Gary Thorpe <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 01/23/2004 12:13:54
In message <firstname.lastname@example.org>,
Gary Thorpe writes:
>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.