From owner-freebsd-questions@FreeBSD.ORG Mon Mar 17 03:11:37 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86916106566B for ; Mon, 17 Mar 2008 03:11:37 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 0FA3B8FC29 for ; Mon, 17 Mar 2008 03:11:35 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id OAA29953; Mon, 17 Mar 2008 14:11:14 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 17 Mar 2008 14:11:13 +1100 (EST) From: Ian Smith To: Wojciech Puchar In-Reply-To: <20080316195620.D24E4106569A@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-questions@freebsd.org Subject: Re: IPFW with user-ppp's NAT X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 03:11:37 -0000 On Sun, 16 Mar 2008 18:20:12 +0100 (CET) Wojciech Puchar wrote: > >> > >> what's wrong in userland natd? > > > > Performance. With userland natd, every packet that passes through natd > > must pass from kernel to userland (causing one context switch) and back > > again (causing another context switch). This will be slower and use more > > CPU than doing it all inside the kernel, without any context switches. > > true, anyway for my two 2Mbps symmetric connection (all for nat), and > three 4/0.5Mbit connections (part for nat, mostly for squid) all natd > processes takes at most 3 percent of single core (core2duo). Sure. And with my little 512/128k ADSL link, soon 1500/256, I doubt you could even measure the difference. I haven't seen any comparative data on high-performance boxes but as Erik points out, it may be significant. Just to make it clear, my point was that one reason for deprecating ipfw is out the door, and that its development is ongoing. I see rc.firewall has had a recent facelift too, including a stateful 'workstation' type. (Sorry that our ancient mail setup blocked your mail; hopefully fixed.) cheers, Ian