bpf, ipfw and before-and-after
jdp at polstra.com
Tue Aug 5 14:01:34 PDT 2003
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 D. Polstra & Co., Inc. Seattle, Washington USA
"Two buttocks cannot avoid friction." -- Malawi saying
More information about the freebsd-net