From owner-freebsd-net@FreeBSD.ORG  Tue Aug  5 12:19:45 2003
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 2ADDC37B401; Tue,  5 Aug 2003 12:19:45 -0700 (PDT)
Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id DF60643F85; Tue,  5 Aug 2003 12:19:43 -0700 (PDT)
	(envelope-from pete@he.iki.fi)
Received: from PETEX31 (h81.vuokselantie10.fi [193.64.42.129])
	by silver.he.iki.fi (8.12.9/8.11.4) with SMTP id h75JJfsL072969;
	Tue, 5 Aug 2003 22:19:42 +0300 (EEST)
	(envelope-from pete@he.iki.fi)
Message-ID: <01ca01c35b86$83c75590$812a40c1@PETEX31>
From: "Petri Helenius" <pete@he.iki.fi>
To: <net@freebsd.org>, "John Polstra" <jdp@polstra.com>
References: <20030805133922.GA7713@k7.mavetju>
	<200308051817.h75IH7jb006622@strings.polstra.com>
Date: Tue, 5 Aug 2003 22:19:38 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
cc: edwin@freebsd.org
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Aug 2003 19:19:45 -0000

>
> 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.

Pete