Jonathan Stone wrote:

> 
> But the original objection I had was to smb's comment about ``stock
> systems'' (note: unqualified in the original) being bad at packet
> capture on a NetBSD mailing list. As opposed to ``stock Linux
> systems'' bing bad at passive packet capture.
>

And besides, packet capture is an unsolved problem:)
When you reconstruct a tcp session, you do it your OS way, not the way 
it'll be considered by the client and server hosts (insertion and 
elusion attacks).

second, if I were to capture, I'll add code to ip_input.c, instead of 
relying on user-level pcap.

So nfr and friends aren't optimal enough to ask for optimal underlying 
implementations.


> And even that is marginally on-topic for a NetBSD technical list.

as long as it doens't kill us...

>>>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.

ahem... I fully understand that polling can't be good unless you get a 
lot of flow, but I have no idea of what "lot" is here. so if someone can 
say how lot this lot is to be before polling, please interrupt my poll.