Buffer size question

[Alexander Dupuy <dupuy () sysd com>]

Guy Harris writes:
> Unfortunately, given that, on systems with BPF, you cannot change the 
> buffer size after a BPF device has been bound to a network interface, 
> "pcap_setbuff()" is unimplementable on those systems, so it's not a 
> candidate for libpcap.

I didn't realize it was possible to set the buffer size with BPF; but indeed it 
is, and I see that it will even support sending up multiple packets from the 
kernel (on my FreeBSD 5.2 box at least), making the buffer size of some actual 
significance.  Odd that the requirement that the BIOCSBLEN ioctl be performed 
before BIOCSETIF isn't documented anywhere, but I'll take your word for it (and 
even if this restriction were eliminated, other systems might have it).

> Some mechanism to supply that information at open time, whether it's an 
> additional argument (which I think is the right long-term answer), a 
> change to libpcap so that it doesn't reduce the buffer size below the 
> default (which libpcap 0.8 already does), or an environment-variable 

I agree that an additional argument is the right long-term answer, but it does 
introduce API compatibility issues.  I find use of an environment variable 
unsatisfactory, for security and other reasons.

Our application actually uses the Linux ring-buffer support (gasp!).  Yes - I 
know that it's not supported/recommended/recognized by the official tcpdump.org 
version, which even most Linux distros have switched over to, but we found the 
ring-buffers to be extremely helpful for our application, and with a few fixes 
to the original library implementation, we're quite happy with the performance 
improvement over the Linux packet socket packet-at-a-time read() API.

Needless to say, we added get/set buffer size calls to our copy of libpcap to 
support larger ring-buffers - as I wasn't aware of the BPF limitation you 
mention, I'm not sure that the API is ideal but I think that it bears some 
consideration.

The functions we added are:

int pcap_getbufsize(pcap_t *p, char *errbuf);
int pcap_setbufsize(pcap_t *p, int bufsize, char *errbuf);

both functions return -1, with error buffer filled in (if non-NULL) on error

pcap_getbufsize returns buffer size on success
pcap_setbufsize returns 0 on success

Although we haven't implemented it, this can be generalized to accept a NULL 
pcap_t *p to get/set the default used for newly pcap_open()d handles, thereby 
allowing the BPF case to be supported as well.

> Note also that other OSes might also have the notion of a settable 
> buffer size, and perhaps the other pcap-*.c files should also check the 
> PCAP_BUFSIZE environment variable.  Those OSes might, or might not, 
> impose their own upper and lower bounds.

Guy actually summarized the OS'es that support configuring the kernel buffers 
back in 2002 (http://www.tcpdump.org/lists/workers/2002/04/msg00023.html).

Although we didn't implement the get/set bufsize functions for other platforms, 
I did some research and found the following:

DEF = default buffer size
DEFMAX = max buffer size without kernel tuning
MAX = inherent limit for kernel buffering

* bpf BIOCSBLEN

        FreeBSD DEF = 4-32K depending
                DEFMAX = 512K-1M
                MAX = 16M(?)
        AIX     ???

* getsockopt/setsockopt(..., SO_RCVBUF, ...)

        Linux   DEF = /proc/sys/net/core/rmem_default = 64K
                DEFMAX = /proc/sys/net/core/rmem_max = 64-256K depending
                MAX = 2G(?)

        IRIX 6  DEF = 64K(?)
                DEFMAX = unlimited(?)
                MAX = unlimited

        SunOS 3 ???

* Linux ring-buffer

        RX_RING DEF = n/a
                DEFMAX = 32K packets * snaplen (4-8M at typical snaplen)
                MAX = 32K packet limit due to max slab size for kmalloc
                        (increase requires recompilation)
        TRECV   DEF = n/a
                DEFMAX = ???
                MAX = ???

* DLPI (Solaris/HP-UX/AIX) SBIOCSCHUNK

        DEF = 8K
        DEFMAX = 64K
        MAX = 256K(?) recommended max high-water mark
        (http://developers.sun.com/solaris/articles/streams_bandwith.html)

* SunOS 4 NIOCSCHUNK

        DEF = 8K
        DEFMAX = ??? (one app sets it to 100K?)
        MAX = ???

* Windows WinPcap driver

        DEF = 1M
        DEFMAX = ???
        MAX = ???

> Anyway, anoncvs at cvs.tcpdump.org isn't working for me: 
> cvs [login aborted]: recv() from server cvs.tcpdump.org: EOF

I'm having this problem as well.  Seems like the anon-cvs pserver is 
misconfigured and/or needs restarting.

@alex


-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.