Re: bpf/pcap performance

[Guy Harris <guy () alum mit edu>]

On Apr 12, 2004, at 2:25 AM, Darren Reed wrote:

> In some email I received from Guy Harris, sie wrote:
> > On Sun, Apr 11, 2004 at 03:15:30AM +1000, Darren Reed wrote:
> > > And there's also BPF_MAXBUFFERSIZE.  I see pcap_getbuff() as being
> > > essential to getting code to work without trial and error by passing
> > > different sizes to read() to find out what the right size to read
> > > is, if you're not setting the size yourself.
> >
> > But if you're using libpcap, you're not passing anything to read(),
> > you're letting libpcap do that.
>
> Not necessarily.
>
> The interface exposed by libpcap is not conducive to good use by
> C++ applications - main culprit here is pcap_dispatch() but none
> of the others really help.  Unless all your classes are static
> classes (which kind of defeats the purpose, in my book.)
>
> So whilst pcap is good for discovering interfaces and setting up the
> sniffing, I've been forced to use pcap_fileno() and read(2) in order
> to get the application design I want.  Using pcap_next() is too slow
> on BSDs where you can get multiple packets per read

So that presumably also applies to "pcap_next_ex()" - which was 
introduced on a platform (Win32/WinPcap) where you can get multiple 
packets per read.

> (on Linux, it is fine.)

...but is "read()" fine on Linux? :-)

I.e., if you're using "read()", you're already not portable, unless you 
are, in effect, re-implementing the dispatch loop for all platforms.  
If your code knows what platform it's using, it could also know to do 
the BIOCGBLEN ioctl.

> Also, I don't believe that the interfaces provided by pcap provide for
> a slimmed down read execution path.

What different interfaces would you suggest?

> > > Maybe not...what I am envisaging, here, is between the pcap_open()
> > > and the pcap_startlive(), a program can interact with BPF to find
> > > out what capabilities it has, what buffer size it will accept, etc,
> > > before turning the tap of packets on.
> >
> > Well, turning the tap of packets on involves binding to the BPF 
> > device -
> > and you currently can't set the buffer size once you've bound to a
> > device.
>
> Well then, maybe we need to give some thought to what we would
> like in terms of useful BPF device behaviour, including being
> able to "turn the tap off" (without closing) or similar ?

...and some thought to whether the "open" and "turn the tap on" split 
can be implemented on other platforms.

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