From owner-freebsd-net Mon Apr 3 18:57:21 2000 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2030937B5D5 for ; Mon, 3 Apr 2000 18:57:17 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id VAA18098; Mon, 3 Apr 2000 21:57:07 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 3 Apr 2000 21:57:06 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Arun Sharma Cc: freebsd-net@freebsd.org Subject: Re: kernel vs user level implementation of NAT In-Reply-To: <20000331234156.A28140@sharmas.dhs.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org While passing all packets through userland can have a performance impact (especially in terms of latency on older machines), throughput is usually not a problem. It performs especially favorably compared to userland firewall proxies, which are notoriously poor in terms of performance impact as they typically run in seperate processes, requiring context switches. I've pushed 50+ mbps streams through userland in some of my own code on a 450mhz PIII, and the limiting factor has in this case been poor ethernet hardware and testing environment, rather than a maxed out box performing the userland filtering. Keeping code in userland makes it *substantially* easier to develop, debug, and maintain. It also makes the code far more portable, and avoids adding more baggage to the in-kernel IP stack, which would reduce our ability to modify the stack to reflect changing needs. I understand that the BSD/OS folks have extended BPF to allow it to modify packets on the fly, as well as do other spiffy things, which provides a nice stack expensibility mechanism while reducing the kernel/userland switches. It may be that as the BSD/OS+FreeBSD code bases draw closer together, we get to see more spiffy features such as that in the public FreeBSD source base. On Fri, 31 Mar 2000, Arun Sharma wrote: > Can someone point me to some discussion or literature on why *BSDs chose > to implement natd as a daemon as opposed to a kernel service ? I'm > particularly interested in the performance (latency) aspects of the issue. > > Thanks in advance, > > -Arun > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message