In message <Pine.NEB.4.58.0401211743110.18750@mail.netbsd.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.)