From owner-freebsd-net@FreeBSD.ORG Tue Nov 11 01:38:00 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 B32F816A4CE for ; Tue, 11 Nov 2003 01:38:00 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A6D643F93 for ; Tue, 11 Nov 2003 01:37:59 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 41068 invoked from network); 11 Nov 2003 09:40:49 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 11 Nov 2003 09:40:49 -0000 Message-ID: <3FB0ADE8.44B00CF9@pipeline.ch> Date: Tue, 11 Nov 2003 10:37:44 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: popsong old References: <20031111063627.45765.qmail@web10004.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review 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, 11 Nov 2003 09:38:00 -0000 popsong old wrote: > > > ip_fastforward > > > - removes ip_flow forwarding code > > - adds full direct process-to-completion IPv4 > forwarding code > > - handles ip fragmentation incl. hw support > (ip_flow did not) > > - supports ipfw and ipfilter (ip_flow did not) > > - supports divert and ipfw fwd (ip_flow did not) > > - drops anything it can't handle back to normal > ip_input > > Should we worry about the locking in IPFilter? It > seems that there are no locking at all in IPFilter for > FreeBSD. I haven't touched ipfilter, but yes, there is currently no locking in ipfilter. This ain't good I suppose. I guess it would be easy to slap a global ipfilter lock on there. We can't go directly into ipfilter to do locking because that would take ipfilter off the vendor branch and would make updating it impossible. > BTW, we'll get even better performance if we keep both > interfaces' MAC addresses in cache (and call > ifp->if_start directly). This requires to keep > ethernet header in mbuf untouched and is only relevant > in ethernet though. I implemented such layer 2 cache > in a local version of IPFilter and got some good > results. I don't understand why you want to do that unless you are doing bridging. We have to look up the mac address of the next hop anyway. If that is not already in the routing table it needs to do a arp lookup. -- Andre