From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 16:53:09 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 E565B37B401 for ; Tue, 5 Aug 2003 16:53:09 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6BCC43F85 for ; Tue, 5 Aug 2003 16:53:08 -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 h75Nr31w001083 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 5 Aug 2003 16:53:03 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.6/8.12.6/Submit) id h75Nr2qC007206; Tue, 5 Aug 2003 16:53:02 -0700 (PDT) (envelope-from jdp) Date: Tue, 5 Aug 2003 16:53:02 -0700 (PDT) Message-Id: <200308052353.h75Nr2qC007206@strings.polstra.com> To: net@freebsd.org From: John Polstra In-Reply-To: <1564916751.1060101774@melange.errno.com> References: <20030805133922.GA7713@k7.mavetju> <01ca01c35b86$83c75590$812a40c1@PETEX31> <200308052101.h75L1WR1006787@strings.polstra.com> <1564916751.1060101774@melange.errno.com> Organization: Polstra & Co., Seattle, WA X-Bogosity: No, tests=bogofilter, spamicity=0.499862, 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: Tue, 05 Aug 2003 23:53:10 -0000 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. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Two buttocks cannot avoid friction." -- Malawi saying