bpf, ipfw and before-and-after

[John Polstra]

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.

John
-- 
  John Polstra
  John D. Polstra & Co., Inc.                        Seattle, Washington USA
  "Two buttocks cannot avoid friction."                     -- Malawi saying