From owner-freebsd-net@FreeBSD.ORG Thu Nov 6 01:10:21 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46073B12; Thu, 6 Nov 2014 01:10:21 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BFAA5FF; Thu, 6 Nov 2014 01:10:20 +0000 (UTC) Received: from 50-206-19-250-static.hfc.comcastbusiness.net ([50.206.19.250]:57613 helo=[10.1.10.186]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1XmBad-0008BB-HE; Wed, 05 Nov 2014 20:10:19 -0500 From: "George Neville-Neil" To: "Alexander V. Chernikov" Subject: Re: IPSEC in GENERIC [was: Re: netmap in GENERIC, by default, on HEAD] Date: Wed, 05 Nov 2014 17:10:18 -0800 Message-ID: <03107CAB-445B-4BA9-8F50-69143E360010@neville-neil.com> In-Reply-To: <545A5C4D.3050603@FreeBSD.org> References: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> <545A5C4D.3050603@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.8r4576) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: "Andrey V. Elsukov" , John-Mark Gurney , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 01:10:21 -0000 On 5 Nov 2014, at 9:20, Alexander V. Chernikov wrote: > On 05.11.2014 19:39, George Neville-Neil wrote: >> Howdy, >> >> Last night (Pacific Time) I committed a change so that GENERIC, on >> HEAD has the netmap >> device enabled. This is to increase the breadth of our testing of >> that feature prior >> to the release of FreeBSD 11. >> >> In two weeks I will enable IPSec by default, again in preparation for >> 11. > Please don't. > > While I love to be able to use IPSEC features on unmodified GENERIC > kernel, simply enabling > IPSEC is not the best thing to do in terms of performance. > > Current IPSEC locking model is pretty complicated and is not scalable > enough. > It looks like it requires quite a lot of man-hours/testing to be > reworked to achieve good performance and I'm not sure > if making it enabled by default will help that. > > Current IPv4/IPv6 stack code with some locking modifications is able > to forward 8-10MPPS on something like 2xE2660. > I'm in process of merging these modification in "proper" way to our > HEAD, progress can be seen in projects/routing. > While rmlocked radix/lle (and ifa_ref / ifa_unref, and bunch of other) > changes are not there yet, you can probably get > x2-x4 forwarding/output performance for at least IPv4 traffic (e.g. > 2-3mpps depending on test conditions). > > In contrast, I haven't seen IPSEC being able to process more than > 200kpps for any kind of workload. > > What we've discussed with glebius@ and jmg@ at EuroBSDCon was to > modify PFIL to be able to monitor/enforce > hooks ordering and make IPSEC code usual pfil consumer. In that case, > running GENERIC with IPSEC but w/o any SA > won't influence packet processing path. This also simplifies the > process of making IPSEC loadable. > How soon do you think the pfil patch would be ready? That sounds like a good first step towards making all this enabled in HEAD so that we can make sure that IPSec gets the broad testing that it needs. Also, if folks who know about these problems can send workloads and test descriptions to the list that would be very helpful. Specific drivers and hardware types would be most helpful as this may be device related as well. I will turn this on on some machines in the network test lab to see what I can see. Best, George