Buffer size question

["Ed Maste" <emaste () sandvine com>]

(I just subscribed to the list so don't have the original
message to reply to.)  I have some more comments on the recent 
thread about the pcap buffer size code in pcap-bpf.c.

The code to try smaller and smaller buffer sizes until a valid size 
is found has the following comment:

        /*
         * Try finding a good size for the buffer; 32768 may be too
         * big, so keep cutting it in half until we find a size
         * that works, or run out of sizes to try.
         *
         * XXX - there should be a user-accessible hook to set the
         * initial buffer size.
         */
        for (v = 32768; v != 0; v >>= 1) {

Modern hardware can get high packet rates through bpf and pcap,
but the default 32k buffer does not allow an application much
latency.  We've (twice) modified libpcap to start with a larger 
initial size, but the comment is correct; there should be a
hook to set the size.

It seems the size will need to be set before pcap_open_live.
I want to offer a few ideas for discussion:

1) Add a new pcap API function pcap_set_bufsize that can be used
to set the size used for following pcap_open_live calls (by setting 
a libpcap global variable).  Existing applications would not be 
affected.  Basically provide the same functionality as pcap_setbuff 
from winpcap, but it has to be called before opening the bpf dev.

2) Add a new function like pcap_open_live that adds a buffer size 
argument.  http://www.tcpdump.org/lists/workers/2000/msg01358.html

3) Use an environment variable (PCAP_BUFFER_MAX?) to set the 
initial trial buffer size.  Existing applications could even use a 
larger size without recompiling.

4) Do a BIOCGBLEN ioctl before trying the initial size.  If the 
size returned is greater than the initial size, just avoid 
BIOCSBLEN.  On FreeBSD I've got a sysctl debug.bpf_bufsize that 
sets the default buffer size, but it has no effect for libpcap.  
The disadvantage is that the same size gets used for all pcap 
users, which might be undesirable.

Any comments on these ideas?

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