From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 14:40:01 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 7FA3C37B401 for ; Wed, 2 Jul 2003 14:40:01 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 716E443FBF for ; Wed, 2 Jul 2003 14:40:00 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 65564 invoked from network); 2 Jul 2003 21:39:59 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 2 Jul 2003 21:39:59 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 2 Jul 2003 18:39:42 -0500 (CDT) From: Mike Silbersack To: Michael Sierchio In-Reply-To: <3F0316DE.3040301@tenebras.com> Message-ID: <20030702183443.C1913@odysseus.silby.com> References: <3F0316DE.3040301@tenebras.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-ipfw@FreeBSD.ORG cc: freebsd-net@FreeBSD.ORG Subject: Re: Performance improvement for NAT in IPFIREWALL 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: Wed, 02 Jul 2003 21:40:01 -0000 On Wed, 2 Jul 2003, Michael Sierchio wrote: > Currently, performance w/divert sockets and natd in ipfirewall > on a compute-bound platform (ELAN-133MHz) shows ipfw+natd throughput > to be 50% of that offered by ipfilter+ipnat. > > Is there anything that can be done to speed up either the > performance of divert and natd? Alternatively, could network > address translation be merged into ipfirewall? > > As we move from 1000BASE-TX to 10000BASE-TX, this will become > more of an issue, even on 3GHz machines. > > 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. :) Mike "Silby" Silbersack