Subject: Re: packet capturing
To: Perry E. Metzger <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 01/20/2004 15:08:03
In message <email@example.com>"Perry E. Metzger" writes
>Jonathan Stone <jonathan@DSG.Stanford.EDU> writes:
>> We could make bpf_bufsize sysctl'able; or raise the default to
>> something that reduces bpf drop at high packet rate (somewhere between
>> 128 and 512k); or both.
>> Which of these would you support?
>Both. The default probably should be jacked up only on larger memory
>machines though (which is an easy calculation during boot...)
there's no hook to set it during boot, and "large" is possibly MD, and
definitely a question of taste. How about this as a compromise:
1. bump the `default' bpf buffersize for naive apps to 32k, and the default
limit (bpf_maxbufersize) to 256k.
2. Make the run-time values sysctl'able (or at least patchable,
since I dont really grok Andew's dynamic sysctl API).
3. Pull in the binary-search heuristic to bpf-pcap's live-capture
routine. Have it search (via BIOCSBLEN) all the way up to a humungous
size, say 4Mbytes. That way, root can set larger values via patch/sysctl
(or dynamic boot-time sizing, if someone wants to add it)
without requiring recompilation of libpcap.