On Thu, Apr 04, 2002 at 04:22:45PM -0500, Ashley Thomas wrote:
> What is the maximum kernel packet capture buffer size that
> can be used at the libpcap layer ?
It depends on the packet capture mechanism libpcap uses.
> I am referring to libpcap over OpenBSD 2.9 which uses bpf
> mechanism.
Then it's whatever BPF_MAXBUFSIZE is defined as in <net/bpf.h>
> Is it possible to start for eg: from 65536 instead of 32768
> so that we will get a bigger buffer thereby reducing possible packet drops
> during bursty traffic scenarios.
> or is it limited by the kernel capabilities ?
It *is* limited by the kernel capabilities.
I don't know whether there are any problems that would be caused by
attempting to set it too large. A couple of possible problems are
1) the system doesn't clip the value at the supported maximum,
and also causes a subsequent BIOCSETIF to fail with an error
*other* than ENOBUFS, so that "pcap_open_live()" fails;
2) the buffer is too large for some application (consumes more
memory than the application needs, wasting memory).
There's not much we can do about the former, but hopefully no OS that
uses BPF is broken enough to do that.
The only way to handle the latter would be to add a new call to open
capture devices, which would take a buffer size as an argument. On
platforms where the buffer size can be set, we'd use it; on other
platforms, we'd ignore the argument.
It can be set on:
BSD systems, using BIOCSBLEN, and possibly AIX's BPF as well;
Windows with WinPcap.
It can *possibly* be set on:
Linux, Irix, and SunOS 3.x, by setting the socket buffer size on
the socket used for capturing (if SunOS 3.x had the API to do
that; I forget whether that was a 4.3BSDism or not - if it was,
it might not've been in 3.x);
at least some versions of SunOS 5.x using SBIOCSCHUNK;
possibly SunOS 4.x as well, if its "bufmod" also supported
SBIOCSCHUNK;
but I don't know whether, on those platforms, the call in question would
have the effect of increasing the amount of captured packet data that
could be buffered in the kernel, and unread from userland, before the
capture mechanism started throwing packet data out.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
