Date: Sun, 8 Apr 2007 10:49:27 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Kris Kennaway <kris@obsecurity.org> Cc: freebsd-net@freebsd.org, Ivan Voras <ivoras@fer.hr> Subject: Re: A radical restructuring of IPsec... Message-ID: <20070408104025.Y77212@fledge.watson.org> In-Reply-To: <20070407042322.GA72639@xor.obsecurity.org> References: <m21wix61iy.wl%gnn@neville-neil.com> <ev5mku$3tq$1@sea.gmane.org> <20070407042322.GA72639@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070408104025.Y77212>