From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 17:05:47 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 F25F537B401 for ; Tue, 5 Aug 2003 17:05:46 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20E9C43FDD for ; Tue, 5 Aug 2003 17:05:46 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange.errno.com (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h7605g7N028235 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 5 Aug 2003 17:05:45 -0700 (PDT) (envelope-from sam@errno.com) Date: Tue, 05 Aug 2003 17:05:42 -0700 From: Sam Leffler To: John Polstra , net@freebsd.org Message-ID: <1566283957.1060103142@melange.errno.com> In-Reply-To: <200308052353.h75Nr2qC007206@strings.polstra.com> References: <20030805133922.GA7713@k7.mavetju> <01ca01c35b86$83c75590$812a40c1@PETEX31> <200308052101.h75L1WR1006787@strings.polstra.com> <1564916751.1060101774@melange.errno.com> <200308052353.h75Nr2qC007206@strings.polstra.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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:05:47 -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. 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? I'm not arguing about keeping up with 10Gb media... Sam