From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 14:01:34 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 8B8AC37B401 for ; Tue, 5 Aug 2003 14:01:34 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 840FE43F93 for ; Tue, 5 Aug 2003 14:01:33 -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 h75L1WXc017816 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 5 Aug 2003 14:01:32 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.6/8.12.6/Submit) id h75L1WR1006787; Tue, 5 Aug 2003 14:01:32 -0700 (PDT) (envelope-from jdp) Date: Tue, 5 Aug 2003 14:01:32 -0700 (PDT) Message-Id: <200308052101.h75L1WR1006787@strings.polstra.com> To: net@freebsd.org From: John Polstra In-Reply-To: <01ca01c35b86$83c75590$812a40c1@PETEX31> References: <20030805133922.GA7713@k7.mavetju> <200308051817.h75IH7jb006622@strings.polstra.com> <01ca01c35b86$83c75590$812a40c1@PETEX31> Organization: Polstra & Co., Seattle, WA X-Bogosity: No, tests=bogofilter, spamicity=0.500000, version=0.11.2 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 21:01:34 -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īs 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. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Two buttocks cannot avoid friction." -- Malawi saying