pcap timeouts are a mystery. Setting the timeout to -1 used to reduce
latency, but that was before we started setting immediate mode. And it
turns out that with that timeout, pcap chews through a lot of CPU
polling its file descriptor, checking timers, etc. However, the
behaviour of setting *no* timeout is defined as, err, undefined. So
instead we set a very long timeout indeed. And loop if it expires.
Fixes#80
pcap timeouts are a mystery. Setting the timeout to -1 used to reduce
latency, but that was before we started setting immediate mode. And it
turns out that with that timeout, pcap chews through a lot of CPU
polling its file descriptor, checking timers, etc.
With no timeout set an idle weave is completely idle - no system calls
at all.
Fixes#80
It turns out that under Linux, libpcap implements the SetDirection
filtering in userspace, causing some spurious wake ups of the packet
capture thread. So set a BPF filter to discard outbound packets inside
the kernel.