From owner-freebsd-net@FreeBSD.ORG Sun Apr 8 09:49:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88C0016A400 for ; Sun, 8 Apr 2007 09:49:28 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 61E2013C44B for ; Sun, 8 Apr 2007 09:49:28 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id DFD73471F8; Sun, 8 Apr 2007 05:49:27 -0400 (EDT) Date: Sun, 8 Apr 2007 10:49:27 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kris Kennaway In-Reply-To: <20070407042322.GA72639@xor.obsecurity.org> Message-ID: <20070408104025.Y77212@fledge.watson.org> References: <20070407042322.GA72639@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Ivan Voras Subject: Re: A radical restructuring of IPsec... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 09:49:28 -0000 On Sat, 7 Apr 2007, Kris Kennaway wrote: > On Fri, Apr 06, 2007 at 04:49:01PM +0200, Ivan Voras wrote: >> gnn@freebsd.org wrote: >> >>> The patch removes Kame derived IPsec from the tree, and adds v6 support to >>> FAST_IPSEC. The IPSEC kernel option is removed, but the FAST_IPSEC option >>> remains. This is a test patch and has a known problem with routing packets >>> through a node. Nodes can operate in a host mode, that is they are the >>> endpoint of a tunnel. >> >> Just a quick question: Is the reason for this simplification, performance, >> cleanup (I see spl...() functions removed), or something else? > > KAME IPSEC is both giant-locked and lower performance than fast IPSEC (which > also integrates with crypto hardware devices). The missing piece from the > latter is what George has implemented, namely IPv6 support. Just to be specific here -- while most of the network stack is MPSAFE, there are a few straggling components that, when compiled into the kernel, require the entire network stack to run with the Giant lock. KAME IPSEC is one of those components, so if you compile KAME IPSEC into your kernel, you see a significant performance loss. The FAST_IPSEC implementation has been MPSAFE since inception, I believe. Eliminating the support infrastructure for non-MPSAFE protocols is a goal for 7.x, but may not be one we reach. Some of the other straggling components are: - i4b - netatm (Skip Ford is working on this) - IPX over IP tunneling (I have a patch, but no volunteers to test it) Of these, i4b is the most worrying since, to date, no one has expressed interest in eliminating its Giant dependency. This means that its future is not bright. Robert N M Watson Computer Laboratory University of Cambridge