Re: libpcap & poll()

[Ben Greear <greearb () candelatech com>]

Aaron Turner wrote:
> On Thu, Nov 13, 2008 at 1:31 PM, Eloy Paris <peloy () chapus net> wrote:
> [snip]
>   
> > One possible reason for high CPU when using poll() or select() is
> > spurious readiness notifications - in this case the program is not
> > sleeping waiting for data but is instead running, causing high CPU.
> >
> > Both the poll() and select() manual pages on Linux have the following
> > comment:
> >
> > "Under Linux, select() may report a socket file descriptor as "ready
> > for reading", while nevertheless a subsequent read blocks. This could
> > for example happen when data has arrived but upon examination has wrong
> > checksum and is discarded. There may be other circumstances in which a
> > file descriptor is spuriously reported as ready. Thus it may be safer to
> > use O_NONBLOCK on sockets that should not block."
> >     
>
> Interesting.  Since most of my development work is on OS X, I didn't
> notice that.
>
>   
> > This has never been an issue for me although you could look into it.
> > This could cause high CPU only if you call pcap_setnonblock() for the
> > packet capture descriptors, and you experience the problem described
> > above, though.
> >
> > Have you recreated the issue that the end-user reports? A very basic and
> > simple troubleshooting technique that has always been very helpful for
> > me is putting a "printf("select() returned %d\n", retval");" after a
> > "retval = select(...)" (in your case poll() ) call. You could tell your
> > user to do that to see how often you're coming back from poll().
> >
> > If the network is pretty busy and there's lots of data to be read from
> > the packet capture descriptors then high CPU is obviously expected. has
> > the user indicated how busy the network is?
> >     
>
> I did ask him about that.  Says traffic is ~400Mbps, but I support
> (and he's using) a BPF filter to only grab a very small subset of that
> (less then 1Mbps).   He says tcpdump runs with much less CPU load so I
> don't think it's a traffic issue.
>
> One unfortunate issue my application has is that since it  sends &
> receives traffic on an interface, every packet I send I usually end up
> reading.  I know some OS's support pcap_setdirection() which helps,
> but last time I checked I don't think Linux is one of them since
> libpcap uses PF_PACKET on the back end.  Still, we're talking about
> less then 2Mbps of traffic which shouldn't cause 100% CPU utilization.
>   
I guess you have some way of knowing you are reading a packet you just wrote
so that you don't do this in a loop?

I do know that if you use a PF_PACKET socket, if you write to it you do not
read that packet back on the PF socket.  I'm not sure about using pcap 
to read/write on Linux,
however.

To see the program's behaviour, I'd also 'strace' it.  That will show 
system calls
and their return values.  It's usually easy to see a busy spin this way...

Thanks,
Ben

--
Ben Greear <greearb () candelatech com> 
Candela Technologies Inc  http://www.candelatech.com


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