Date: Tue, 5 Aug 2003 17:16:34 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: net@freebsd.org Cc: sam@errno.com Subject: Re: bpf, ipfw and before-and-after Message-ID: <200308060016.h760GYYC007306@strings.polstra.com> In-Reply-To: <1566283957.1060103142@melange.errno.com> References: <20030805133922.GA7713@k7.mavetju> <1564916751.1060101774@melange.errno.com> <200308052353.h75Nr2qC007206@strings.polstra.com> <1566283957.1060103142@melange.errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <1566283957.1060103142@melange.errno.com>, Sam Leffler <sam@errno.com> wrote: > > In article <1564916751.1060101774@melange.errno.com>, > > Sam Leffler <sam@errno.com> wrote: > >> > 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. > > > > That does not follow, because the check of ifp->if_bpf itself takes > > time. There is no way to avoid the performance penalty except at > > compile time. Yes, branch prediction helps, but it doesn't eliminate > > the problem. Even with gigabit ethernet those individual nanoseconds > > add up quickly to the point where they matter. With 10 Gb ethernet on > > the way, it will only get worse. > > You said there were calls to bpf_mtag and they would add noticeable > overhead even when BPF was not in use. I said these are only made when BPF > is in use. What doesn't follow? What doesn't follow is, "So any slow down should only happen when BPF is active." John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Two buttocks cannot avoid friction." -- Malawi saying
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200308060016.h760GYYC007306>