Subject: Re: bpf/pcap performance
To: Guy Harris <guy@alum.mit.edu>
From: Darren Reed <darrenr@reed.wattle.id.au>
List: tech-net
Date: 04/10/2004 08:04:28
In some email I received from Guy Harris, sie wrote:
> 
> On Apr 9, 2004, at 2:17 PM, Darren Reed wrote:
> 
> > Really?  So....hmmm....this isn't what I was expecting.  I should have
> > paid closer attention to what the code was doing rather than trusting
> > it was setting it and working.  You might have suspected that this code
> > was originally written on Windows and has been ported back to Unix and
> > given that the function is present, no consideration was given to 
> > whether
> > or not the code actually did anything.
> 
> The function isn't even present on tcpdump.org's libpcap for UN*Xes; 
> did you use a modified version of libpcap?  (If so, perhaps they *have* 
> figured out a way to set the buffer size after the BPF device is bound 
> to an interface, although I don't see one from looking at the kernel 
> BPF code; if they have, we'd be interested in adding that to 
> tcpdump.org's libpcap.)

Ok and me checking now agrees - it is something I've added, probably
for compatibility with Win32 code. I imagine ti was just doing a
copy-paste from pcap_open_live() and hoping that works as expected
(which it didn't but didn't return a failure either.)

btw, thoughts on pcap_getbuff() ?

> 	1) new options can be added over time as necessary (e.g., perhaps 
> adding "monitor mode", channel, etc. options for 802.11) without having 
> to change the API;

If you're going to do this, maybe it is sensible to breakup
pcap_open_live() to be something like this:

pcap_open("/dev/bpf0")
pcap_setparams(paramarray) [NIC,promisc,snaplen,toms,bufsize,DLT,...]
pcap_startlive()

and having a _setparams() might lead on to a _getparams().

If you want to go down this path (or similar), I think some work
should be done on bpf.c, as well, to improve the interface there,
such that you have more flexibility in libpcap and applications.
Apart from code bloat (if people want to retain BPF compatibility),
I can't see why changing the kernel side should be ruled out :)

Sitting here, I'm looking at this thinking there's a general
design choice you've got to make here - have a single function
and some sort of variable arg list to set/get parameters or
to use a set/get function pair for each.  If the capabilities
are going to evolve and vary a lot over time, my own thoughts
would be to use a param list as you've suggested as a way of
easing interface compatiblities and programming ones if the
magic numbers are all #defines.

> BTW, is there any reason why libpcap shouldn't just set the buffer size 
> to the maximum on BPF systems?  Is there a concern that it'd chew up 
> too much wired-down memory if lots of applications that don't need a 
> large buffer (e.g., because they're capturing with a filter that 
> discards most packets) run with one?

I can't answer that.  I do find it strange, however, that the code
doesn't allow BIOCSBLEN after the NIC has been assigned, though.
It's does not appear that there's any reason why it can't be done,
someone's just chosen not to allow it.

Also, having looked at the BPF code, the kernel allocates 2*buffersize
when you do the BIOCSETIF.

Darren

p.s. I've added tcpdump-workers to the cc-list, feel free to remove
tech-net@netbsd.org when replying to move this discussion to where
it should be :)