From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 12:14:06 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 300421065678 for ; Tue, 28 Apr 2009 12:14:06 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id E02DE8FC2C for ; Tue, 28 Apr 2009 12:14:05 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id EF9F42798B8; Tue, 28 Apr 2009 13:55:30 +0200 (CEST) Received: by astro.zen.inc (Postfix, from userid 1000) id 304B61705A; Tue, 28 Apr 2009 14:03:11 +0200 (CEST) Date: Tue, 28 Apr 2009 14:03:11 +0200 From: VANHULLEBUS Yvan To: Jan Melen Message-ID: <20090428120311.GA68397@zeninc.net> References: <49F5B6F8.4040808@melen.org> <49F5F4A6.8050902@freebsd.org> <20090427182917.W15361@maildrop.int.zabbadoz.net> <49F6A3EA.3090905@melen.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F6A3EA.3090905@melen.org> User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-hackers@freebsd.org Subject: Re: IPsec in GENERIC kernel config X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 12:14:06 -0000 On Tue, Apr 28, 2009 at 09:36:26AM +0300, Jan Melen wrote: > Hi, [...] > Just to understand the problem correctly I guess you are talking about > performance hit on outgoing packets as the IPsec tries to find a > security policy even for packets that should not be encrypted? For > incoming traffic I don't see any reason for performance hit. The (more or less) same check is done for incoming packets, because we NEED to ensure that IPsec traffic comes from the appropriate IPsec tunnel, and non IPsec traffic comes without IPsec.... > Has anyone done any measurements on magnitude of performance loss we get > from trying to match the outgoing packets for non-existent IPsec > policies? I would guess that if you have zero SPD entries in your system > it can't be a lot as it a matter of calling: > ip_ipsec_output -> ipsec4_checkpolicy -> ipsec_getpolicybyaddr/sock -> > key_allocsp which in turn searches through an empty list. We (my company) already tried such a hack, which completely skips IPsec process if we know that SPD (both in and out) is empty. It works, and has the expected impact on performance loss. Yvan.