libpcap sniffing time penalty on Linux

[stealth]

Using newest libpcap on linux, I have a delay of ~0.3s before a packet is
returned via pcap_dispatch(). Kernel is 3.14 and the problem is only with packet-ring.
Disabling packet ring via configure has no such delay (verified by strace
using recvfrom()). The problem was once fixed in
feab221 (I think) but seemed to be reintroduced by V3 mmap handling code?

Anyone else experianced such time delays on certain kernel/pcap combinations?

[stealth]

checking out feab221 indeed "fixes" the problem, but packet ring support seems to
be disabled by configure (and cant be enabled) so recvmsg() is still in place. Maybe the poll()
in the ring case has unacceptable time overhead?

[guyharris]

I have a delay of ~0.3s before a packet is returned via pcap_dispatch().

Libpcap makes no guarantee, and has never made any guarantee, that packets will be delivered immediately, the instant that they arrive, unless you enable "immediate mode" by calling pcap_set_immediate_mode() between pcap_create() and pcap_activate(). Otherwise, there is no guarantee that packets will be delivered to its caller before the timeout specified in pcap_open_live() or pcap_set_timeout() expires.

If you want immediate packet delivery, use immediate mode; if you want buffering, to deliver multiple packets per wakeup, don't use immediate mode and set the timeout appropriately.

[infrastation]

There's a man page, there's a recurring question, the only missing element is a FAQ page. Just an idea. :-D

[stealth]

Thanks for the reply. Using pcap_set_immediate_mode() seems to work with packet-ring.

[infrastation]

For posterity, there is now a FAQ entry about this.