From owner-freebsd-ipfw@FreeBSD.ORG Wed Jul 2 15:42:50 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4768937B409 for ; Wed, 2 Jul 2003 15:42:50 -0700 (PDT) Received: from cultdeadsheep.org (charon.cultdeadsheep.org [80.65.226.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9104543FF3 for ; Wed, 2 Jul 2003 15:42:47 -0700 (PDT) (envelope-from sheepkiller@cultdeadsheep.org) Received: (qmail 28047 invoked from network); 2 Jul 2003 22:42:45 -0000 Received: from unknown (HELO chuck.cultdeadsheep.org) (192.168.0.12) by goofy.cultdeadsheep.org with SMTP; 2 Jul 2003 22:42:45 -0000 Date: Thu, 3 Jul 2003 00:42:26 +0200 From: Clement Laforet To: Mike Silbersack Message-Id: <20030703004226.026fdfa4.sheepkiller@cultdeadsheep.org> In-Reply-To: <20030702183443.C1913@odysseus.silby.com> References: <3F0316DE.3040301@tenebras.com> <20030702183443.C1913@odysseus.silby.com> Organization: tH3 cUlt 0f tH3 d3@d sH33p X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-portbld-freebsd5.1) X-Face: ._cVVRDn#-2((lnfi^P7CoD4htI$4+#G/G)!w|,}H5yK~%(3-C.JlEYbOjJGFwJkt*7N^%z jYeu[;}]}F"3}l5R'l"X0HbvT^D\Q&%deCo)MayY`);TO Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-ipfw@FreeBSD.ORG cc: freebsd-net@FreeBSD.ORG Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2003 22:42:50 -0000 Hi, On Wed, 2 Jul 2003 18:39:42 -0500 (CDT) Mike Silbersack wrote: > > Comments? Suggestions? Vision? > > If you have some time to throw at the problem, you might consider > using gprof on natd in order to determine what exactly about natd is > slow. As is commonly mentioned, the kernel <-> userspace switch is > probably one reason for natd's relative slowness, but I would bet that > a decent speedup could be achieved just by optimizing natd. Heck, it > might be as simple as increasing the size of some hash tables or > buffers. > > Tell us how it goes. :) Few weeks ago, I've post a patch which impoves natd for INCOMING connections (and breaks some options), I ran gprof to find where natd and libalias lack of performance : 1. sendto(), recvfrom() [natd] an gettimeofday() [libalias] eat a lot of CPU 2. [libalias] hash tables for incoming pakets is VERY poor since the hash is based on alias address, it's mandatory for outgoing connections I think, but for incoming redirect, it eats a lot of time (47% according to gprof under heavy load), since the hash key is the same for all incoming packets. 3. expire mecanisms is too slow, having small tables under heavy load slows NAT'ing drastically. I had best performance with #define LINK_TABLE_OUT_SIZE 4091 #define LINK_TABLE_IN_SIZE 8123 4. matching might be improved to. Better with tables dedicated to redirects ("only" ~50% of CPU time, for ~55Mbp/s on a PIII 700, 90% of this CPU time was used by syscalls). My 2cts... If somebody cares, I'm currently writing an in-kernel && in-ipfw NAT to perform load balancing, if you have any suggestion, I'm all ears :) Regards, clem