Subject: Re: packet capturing
To: Darren Reed <firstname.lastname@example.org>
From: Jonathan Stone <email@example.com>
Date: 01/21/2004 12:22:02
In message <Pine.NEB.firstname.lastname@example.org>Darren Reed write
>That there are serious problems with "standard" BPF performance is well
>known since NFR
Longer, possibly. Vern Paxson was well aware of it back when he was
still at LBL.
>looked at using it for its first range of products some
>years ago now. To sit back and say "my super-fast PC has no problem"
Darren, take a couple of deep breaths. Y ou've totally missed my
point, so, here it is again:
1. that was a stock Dell machine that I happened
to have around; not superfast at all.
2. That machine was acutally __handling__ the ``DoS'' traffic
in question, as well as keeping up. As the closest I could
come to a slow machine.
3. Most of the NetBSD developers here *know* the default bpf buffer
sizes are too small. If we do serious packet capture, we
increase them by several powers of two: from 32k up to a megabyte or
so. Once that's done, even a 133 Pentium can do a reasonable job
at keeping up with a real-life 100 Mbit stream.
At that point one should start to ask, seriously, just what
Luca Deri's paper is telling us.
4. I have committed changes to our tree to make that 1 Mbyte
buffer size the default *for libpcap* (i.e., tcpdump, ethereal, ...)
and available to other native bpf apps, if the authors want it.
5. At that point, Luca Deri's packet-capture statistics are a strawman.
The context-switch overhead, and number of invocations of the bpf
copyout machinery, have dropped by a factor of 32.
6. As I said earlier: driver polling __is not necessary__.
Modern NICs in the US $20 range provide good Rx interrupt deferal,
to the point where polling simply doesn't buy anything significant.
Really. I tell you three times.
Sure, there may well be some benefit to the ring-buffer API to avoid
the copy overhead. But if there were any worthwhile conclusions *about
bpf* in that paper, they are no longer directly relevant, since we're
no longer measuring the same thing. (and I defy you to find any
worthwhile concliusions about BPF in that paper, above and beyond
Table 1, which says FreeBSD BPF is 68 times better than stock Linux.)