On Apr 25, 2012, at 12:48 PM, Michael Tuexen wrote:
> So it adds copying, but we did some measurements and if you make the queue large, it can improve
> the capturing, because you can store packets as long as you can allocate memory. On Mac OS X we
> could reduce the packet drop rate...
If a bigger buffer reduces the drop rate, that means that the problem is packet bursts or that the test capture didn't run long enough (if the packets are coming in faster than they can be written to disk at all, eventually the buffer fills up).
There's already buffering in BPF, and that buffering should work just as well as any other buffering.
However, unless I'm missing something, dumpcap, at least, defaults to whatever buffer size libpcap/WinPcap default to...
...and, in Snow Leopard, that's a gigantic 32KB:
http://www.opensource.apple.com/source/libpcap/libpcap-23.1/libpcap/pcap-bpf.c
http://www.opensource.apple.com/source/xnu/xnu-1504.15.3/bsd/net/bpf.h
In Lion, libpcap:
http://www.opensource.apple.com/source/libpcap/libpcap-27/libpcap/pcap-bpf.c
overrides BPF's still-32KB default:
http://www.opensource.apple.com/source/xnu/xnu-1699.24.23/bsd/net/bpf.h
and sets the buffer size to 512KB (the maximum that BPF allows) if it hasn't explicitly been set. (That was a change I put into libpcap 1.1, because about all I can say about 32KB as a default in libpcap is "1992 called, they want their typical machine configuration back" :-) Snow Leopard has 1.0.x; Lion has 1.1.x.)
Various *BSDs have, I think, similar issues.
dumpcap appears to set the buffer size explicitly, on platforms that support it (libpcap 1.0 and later, WinPcap) *only* if it's bigger than 1MB, and dumpcap's default is 1MB, so, in practice, dumpcap will *not* set the buffer size by default, which means that, in practice, it won't increase it above 32KB in Snow Leopard.
I think the
if (interface_opts->buffer_size > 1) {
in dumpcap should be
if (interface_opts->buffer_size != 0) {
so that even if it's the 1MB default it still gets used.
