From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 16:42:59 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 6DDE237B404 for ; Tue, 5 Aug 2003 16:42:59 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C3E843F93 for ; Tue, 5 Aug 2003 16:42:58 -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 h75Ngt7N028153 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 5 Aug 2003 16:42:57 -0700 (PDT) (envelope-from sam@errno.com) Date: Tue, 05 Aug 2003 16:42:55 -0700 From: Sam Leffler To: John Polstra , net@freebsd.org Message-ID: <1564916751.1060101774@melange.errno.com> In-Reply-To: <200308052101.h75L1WR1006787@strings.polstra.com> References: <20030805133922.GA7713@k7.mavetju> <200308051817.h75IH7jb006622@strings.polstra.com> <01ca01c35b86$83c75590$812a40c1@PETEX31> <200308052101.h75L1WR1006787@strings.polstra.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: Tue, 05 Aug 2003 23:42:59 -0000 > In article <01ca01c35b86$83c75590$812a40c1@PETEX31>, > Petri Helenius 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=B4s 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. In -current I believe all the calls are prefixed with a check for=20 ifp->if_bpf or similar. So any slow down should only happen when BPF is=20 active. Sam