bpf, ipfw and before-and-after

[Petri Helenius]

>
> 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.

Pete