From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 17:16:40 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9D4737B404 for ; Tue, 5 Aug 2003 17:16:40 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FF2043F75 for ; Tue, 5 Aug 2003 17:16:39 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.12.3p2/8.12.3) with ESMTP id h760GY1w001210 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 5 Aug 2003 17:16:35 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.6/8.12.6/Submit) id h760GYYC007306; Tue, 5 Aug 2003 17:16:34 -0700 (PDT) (envelope-from jdp) Date: Tue, 5 Aug 2003 17:16:34 -0700 (PDT) Message-Id: <200308060016.h760GYYC007306@strings.polstra.com> To: net@freebsd.org From: John Polstra 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> Organization: Polstra & Co., Seattle, WA X-Bogosity: No, tests=bogofilter, spamicity=0.500535, version=0.11.2 cc: sam@errno.com Subject: Re: bpf, ipfw and before-and-after X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2003 00:16:41 -0000 In article <1566283957.1060103142@melange.errno.com>, Sam Leffler wrote: > > In article <1564916751.1060101774@melange.errno.com>, > > Sam Leffler 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