From owner-cvs-all@FreeBSD.ORG Sat May 8 22:16:24 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69E2F16A4CE; Sat, 8 May 2004 22:16:24 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C689643D5C; Sat, 8 May 2004 22:16:23 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004050905162201400jjvkee>; Sun, 9 May 2004 05:16:23 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA15395; Sat, 8 May 2004 22:16:22 -0700 (PDT) Date: Sat, 8 May 2004 22:16:21 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo In-Reply-To: <20040508101459.A98855@xorpc.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: src-committers@FreeBSD.org cc: Andre Oppermann cc: "Jacques A. Vidrine" cc: cvs-src@FreeBSD.org cc: Darren Reed cc: cvs-all@FreeBSD.org cc: Sam Leffler Subject: Re: cvs commit: src/sys/netinet ip_fastfwd.c ip_input.c ip_var.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2004 05:16:24 -0000 On Sat, 8 May 2004, Luigi Rizzo wrote: > On the principle, I tend to agree with Darren here... > it is not nice to replicate functionality in multiple places > by using specialized code instead of relying on (and > possibly optimizing) the generic one. It makes a lot harder > to clean up the replication later, and i believe Andre knows > that quite well given the cleanup work he has done in the past > in the network stack. > While I agree in general that a firewall can do option 2, it can not do "ignore options". So I'm not sure it's an exact duplication of functionality. > I don't think it is worth making a bit fuss about this particular > change, but certainly, as a general principle, we should try as > much as possible to use the generic mechanisms when available -- > especialliy given that performance killers are elsewhere (locking > etc.). > > cheers > luigi > > On Sat, May 08, 2004 at 08:25:31AM -0700, Darren Reed wrote: > > On Fri, May 07, 2004 at 07:55:36AM -0700, Sam Leffler wrote: > > > > > > Employing a packet filter is not equivalent as it requires every packet to be > > > processed while this (effectively 7-line change) adds no new overhead to the > > > normal processing path for packets. It would be nice if packet filtering > > > were cheap enough that we could use it in this way but I don't think that's > > > the case just yet. > > > > Using that argument, is that clearance to put all of the normalization > > from pf into the various parts of the networking code (not every type of > > normalisation needs to be done on every packet but it is all useful), with > > sysctls to turn it on or off, and maybe we'll add the ability to log packets > > at various points because we don't want the overhead of BPF (it has to > > process every packet too) and that's just for starters. I'm sure I can > > think of some more, in time. How about you? > > > > If there were a core@ for freebsd that was active, this is the kind of > > thing I'd be writing to them about, asking for it to be backed out. > > > > Darren >