Date: Sat, 8 May 2004 22:16:21 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Luigi Rizzo <rizzo@icir.org> Cc: Sam Leffler <sam@errno.com> Subject: Re: cvs commit: src/sys/netinet ip_fastfwd.c ip_input.c ip_var.h Message-ID: <Pine.BSF.4.21.0405082214570.95616-100000@InterJet.elischer.org> In-Reply-To: <20040508101459.A98855@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0405082214570.95616-100000>