> I would think, but without even having looked at NFR, that they are
> referring to the Linux Socket Filter option in 2.2, which is equivalent to
> the Berkeley Packet Filter except that it filters on a socket instead of a
> device. LSF provides a BPF engine, so once libpcap is patched correctly, a
> different section of code in libpcap will be used to do filtering, which
> could remove that timeout problem.
NFR's problem is, I infer from stuff I saw on their Web site, that
there's no way in a standard Linux 2.0[.x] kernel to have the kernel
throw out packets deemed "uninteresting" before copying them up to
userland and waking up something reading from a SOCK_PACKET socket -
every single packet on the network gets copied up to userland, and has
to be filtered out there.
Other systems' raw link layer access mechanisms typically have some way
of passing a packet filter into the kernel, either BPF or CMU/Stanford
stack-machine packet filter, so that most packets can be discarded
without copying the entire captured contents to userland, thus saving a
fair bit of CPU time, context switches, etc..
I think the inability to do that, rather than the lack of a timeout, is
what's causing NFR's problem; the machine can't keep up with the stream
of packets coming in, because every one of those packets have to be
copied up to NFR in userland. The page at
http://www.nfr.com/nfr/NFR_FAQ.html
says:
Why does my Linux box not seem to be able to keep up with my
network?
Question:
Seems that my Linux box is having trouble keeping up with the
traffic on my network. I have tried a BSDI, Sun and FreeBSD
version and they have no problems keeping up. What's wrong?
Answer:
We too have seen that. We noticed extremely high packet loss on
a P90 Linux box while comparing it to *no* packet loss on a BSDI
P75 on the same network at the same time. The difference in
performance is a result of the use of a different mechanism to
get packets off the wire. Linux does not have bpf calls in the
NIC drivers, so libpcap uses an alternate mechanism to get
packets out of the kernel. This mechanism does not appear to
have been designed with performance in mind.
If you are interested in the exact reasons that libpcap performs
poorly on Linux see the function pcap_read() in pcap-linux.c
Note that this function will be called for *every* packet read,
and also that it loops through calls to recvfrom() and strcmp()
at least once each time it is called. Compare this with the
same function in pcap-bpf.c.
We are considering possible approaches to this problem.
The Linux Socket Filter should fix that, if the problem is what I think
it is (although I'm a little suspicious, given that Solaris 2.x doesn't
have BPF calls in its NIC drivers, either - and "libpcap", which NFR
uses, doesn't try to compile filter expressions into CMU/Stanford packet
filter code; perhaps NFR generates that code itself, uses
"pcap_fileno()" to get the raw file descriptor for the DLPI device, and
does its own "ioctl"s to install the filter, but can't do anything
similar for Linux 2.0[.x] because there *is* no in-kernel filtering),
but I don't *think* it'd remove the timeout problem.
Then again, the timeout problem might just exist because LBL weren't
given a patch to support the "to_ms" argument to "pcap_open_live()" on
Linux, or because they haven't yet incorporated it into a "libpcap"
release - I can't get to the K-Arp-Ski site for some reason, right now,
so I can't check the patch that I think is there for "libpcap", but if
it just adds support for the "to_ms" argument, that'd be sufficient to
fix the timeout problem.
(The URL for K-Arp-Ski in my bookmarks file is
http://mojo.calyx.net/~btx/karpski.html
but attempts to connect to port 80 of "mojo.calyx.net" get "Connection
refused".
If he doesn't have a patch for "libpcap" 0.4, I'll look into applying it
to 0.4.)
