In message <87znciqm2r.fsf@snark.piermont.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.