Re: libpcap & poll()

["Aaron Turner" <synfinatic () gmail com>]

On Thu, Nov 13, 2008 at 1:34 PM, Ben Greear <greearb () candelatech com> wrote:
> Aaron Turner wrote:
> > I've been told by an end user under Linux 2.6.x at least that, he's
> > seeing very high CPU utilization numbers with tcpbridge which uses
> > libpcap to read packets.  Sounds like the cause of the issue is that
> > I'm using poll() to determine when to read from libpcap.  I'm using
> > poll() because my code listens on multiple interfaces, hence I need a
> > way to look at multiple pcap handles.
> >
> > Questions basically boil down to:
> > 1) Is this expected?
> > 2) Is there a better way?
>
> poll is good generally.
>
> Are you reading multiple packets when poll says the descriptor
> is readable?

yes, I'm passing -1 as the count to pcap_dispatch() on the active pcap
handle(s).

> If you set the descriptor to non-blocking mode, you can read as
> many as are available each loop...

So basically instead of using poll(), use pcap_setnonblock() on both
handles, and then use pcap_dispatch() in a loop, processing both
handles?

basically:

int keep_processing = 1;

pcap_setnonblock(pcap1, 1, errbuf);
pcap_setnonblock(pcap2, 1, errbuf);
do {
   pcap_dispatch(pcap1, -1, &callback, &keep_processing);
   pcap_dispatch(pcap2, -1, &callback, &keep_processing);
} while(keep_processing);

Is this going to be portable & consistent?  I remember there being
some issues with something like this under Solaris with timeouts- i
think it was the timeout didn't start counting down until the first
packet arrived or something like that.  I would of assumed that using
poll() would be more efficient since the code effectively blocks until
a packet arrives rather then looping constantly even when idle.

-- 
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.  -- Benjamin Franklin
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.