Re: libpcap & poll()

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

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.

-- 
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.