Subject: Re: packet capturing
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: mouss <email@example.com>
Date: 01/23/2004 00:15:35
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
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
> 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.