From owner-freebsd-stable@FreeBSD.ORG Wed Mar 23 16:49:05 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD9BF16A4CE for ; Wed, 23 Mar 2005 16:49:05 +0000 (GMT) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92E8F43D3F for ; Wed, 23 Mar 2005 16:49:04 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)j2NGmji8001946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Mar 2005 01:48:45 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 24 Mar 2005 01:48:44 +0900 Message-ID: From: Hajimu UMEMOTO To: Sam Leffler In-Reply-To: <4239B796.80303@errno.com> References: <6.2.1.2.0.20050315112131.054b56f8@64.7.153.2> <4237523B.7090005@errno.com> <4238782A.7010606@errno.com> <4239B796.80303@errno.com> User-Agent: xcite1.38> Wanderlust/2.13.3 (You Oughta Know) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-PRERELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b3 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Thu, 24 Mar 2005 01:48:46 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on cheer.mahoroba.org cc: freebsd-stable@freebsd.org Subject: Re: RELENG_5 and FAST_IPSEC limits X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2005 16:49:05 -0000 Hi, >>>>> On Thu, 17 Mar 2005 09:00:06 -0800 >>>>> Sam Leffler said: sam> Possibly; I can't tell from the patch if locks are held across calls sam> they should not be. I also worry about the effect of holding the various sam> locks for an extended period of time (will it impact packet processing?) Since key_setdump() which is substantial function of KEYCTL_DUMPSA sysctl does in much the same way as key_dump(), I added locking in a similar manner. So, I believe period of time for holding the locks is differ little from key_dump(). However, sysctl required calling key_setdump() twice; 1st is for getting data size and 2nd is for actuall query. sam> Are you suggesting KAME code can/will change to eliminate the use of sam> PF_KEY sockets to query the SA db state? It seems that SADB_DUMP is useless on large system, and we need an alternative for it. Once we introduce an alternative, we don't need SADB_DUMP within our tree. However, SADB_DUMP is defined in RFC 2367 and deployed. So, we should not eliminate it for now. I hope it should be deprecated in the future. The reason I'm going to bring KEYCTL_DUMPSA sysctl into FreeBSD is that there is implementation and Racoon supports it as well. NetBSD has KEYCTL_DUMPSA already, and OpenBSD added similar sysctl recently. I wonder if KEYCTL_DUMPSA sysctl is good for alternative. We need to call sysctl twice for variable length data such as SA dump. It may become overhead. Further, data size is unassured to be same between these two sysctl call. If data grows, 2nd sysctl call will fail. In anyway, it solves a limitation of SADB_DUMP. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/