bpf, ipfw and before-and-after

[Sam Leffler]

> In article <01ca01c35b86$83c75590$812a40c1 at PETEX31>,
> Petri Helenius <pete at he.iki.fi> wrote:
>> >
>> > This would add additional delays to the code path for both ingress
>> > and egress.  In a world where gigabit ethernet is becoming the norm,
>> > every nanosecond counts.  I don't think the benefits of your proposal
>> > would justify the performance loss.  At the very least, I'd want the
>> > extra calls to bpf_mtap to be present in the code only if enabled by
>> > an option in the kernel config file.
>> >
>> bpf is slow by design because the design mandates a packet copy.
>>
>> It´s not a justification to make it slower but gigabit performance out
>> of bpf is just not there until memory speeds increase a lot or the
>> copying goes away.
>
> My point is that the extra calls to bpf_mtap would harm performance
> even when bpf wasn't being used.

In -current I believe all the calls are prefixed with a check for 
ifp->if_bpf or similar.  So any slow down should only happen when BPF is 
active.

	Sam