Subject: Re: packet capturing
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Darren Reed <darrenr@mail.netbsd.org>
List: tech-kern
Date: 01/22/2004 05:18:09
On Wed, 21 Jan 2004, Jonathan Stone wrote:
> I still dont understand anywhere the paper has to say _anything_ about
> *BPF* perfomance, above and beyond Table 1. (Unless you count Figure
> 1, which is is grouns to reject the paper, all on its own).
What about table 4? Although it's hard to tell if the cicular
buffer has had any real measurable difference (99.5% -> 99.9%).
FWIW, my personal interest in this is I'm working on a project where we
need 99.999%, at least, of all packets and preferably 100%, gauranteed,
on a box with 4x100BT connections running at full speed.
> I agree totally with the point about increaseing default packet
> capture. Why don't you lighten up, leave off discussing bad, bad
> papers that simply aren't relevant to NetBSD, and observe that,
> (in fact), I'm committing most of the things you're suggesting?
I don't read source-changes (please, no flames) so unless I see
something mentioned here (or elsewhere) about what people are
doing, I'm often in the dark (just so you know.)
Anyway, in a later email you confused me. You said:
> For the record: I've commited changes to libpcap that will automatically
> probe for, and use, bpf buffers up to 4 Mbytes without recompilation.
> I've also increased the default limit for bpf BIOCSBLEN to 1 Mbyte,
> and confirmed that libpcap uses a 1 Mbyte bpf buffer.
Shouldn't BIOCSBLEN also accept upto 4MB here, then ?
Otherwise I'm confused by this comment...?
Now, in relation to this (and yes I was aware of it):
> Well, sure, except _most_ applications don't use bpf directly; they
> use libpcap. And (last I looked) libpcap doesnt have an API for
> controlling the underlying capture-buffer size.
> If we want to change that, I think we'd have to change our libpcap and
> the tcpdump.org version, and wait for third-party apps to catch up.
This issue has been brought up on tcpdump-workers before as I think
winpcap has an interface to change the buffer size but libpcap does
not (I'd need to check the archives of that list to see what the
result of the discussion was.) There is this comment in pcap_open_live()
too:
* XXX - there should be a user-accessible hook to set the
* initial buffer size.
Maybe it's time to give libpcap a little push here and evolve the
one in NetBSD first ?
Thank you for spending time on this.
Cheers,
Darren