Date: Wed, 05 Nov 2014 17:10:18 -0800 From: "George Neville-Neil" <gnn@neville-neil.com> To: "Alexander V. Chernikov" <melifaro@FreeBSD.org> Cc: "Andrey V. Elsukov" <ae@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>, net@freebsd.org Subject: Re: IPSEC in GENERIC [was: Re: netmap in GENERIC, by default, on HEAD] 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?03107CAB-445B-4BA9-8F50-69143E360010>