tcpdump mailing list archives
Re: libpcap & poll()
From: Ben Greear <greearb () candelatech com>
Date: Thu, 13 Nov 2008 20:15:31 -0800
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 notread 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.
Current thread:
- Re: libpcap & poll(), (continued)
- Re: libpcap & poll() Ben Greear (Nov 13)
- Re: libpcap & poll() Aaron Turner (Nov 13)
- Re: libpcap & poll() Ben Greear (Nov 13)
- Re: libpcap & poll() Eloy Paris (Nov 13)
- Re: libpcap & poll() Ben Greear (Nov 13)
- Re: libpcap & poll() Gianluca Varenni (Nov 14)
- Re: libpcap & poll() Eloy Paris (Nov 14)
- Re: libpcap & poll() Aaron Turner (Nov 13)
- Re: libpcap & poll() Ben Greear (Nov 13)
- Re: libpcap & poll() Eloy Paris (Nov 13)
- Re: libpcap & poll() Aaron Turner (Nov 13)
- Re: libpcap & poll() Ben Greear (Nov 13)
- Re: libpcap & poll() Aaron Turner (Nov 13)
- Re: libpcap & poll() Ben Greear (Nov 13)
- Re: libpcap & poll() Aaron Turner (Nov 13)
- Re: libpcap & poll() Aaron Turner (Nov 13)
- Re: libpcap & poll() Gianluca Varenni (Nov 14)
- Re: libpcap & poll() Ben Greear (Nov 14)