Date: Thu, 6 Nov 2014 11:46:06 +0000 From: "Bjoern A. Zeeb" <bz@FreeBSD.org> To: George Neville-Neil <gnn@neville-neil.com> Cc: "Alexander V. Chernikov" <melifaro@FreeBSD.org>, FreeBSD Net <net@freebsd.org> Subject: Re: IPSEC in GENERIC [was: Re: netmap in GENERIC, by default, on HEAD] Message-ID: <65C48D3B-0C08-4F8F-AF19-239238E49E62@FreeBSD.org> In-Reply-To: <03107CAB-445B-4BA9-8F50-69143E360010@neville-neil.com> References: <92D22BEA-DDE5-4C6E-855C-B8CACB0319AC@neville-neil.com> <545A5C4D.3050603@FreeBSD.org> <03107CAB-445B-4BA9-8F50-69143E360010@neville-neil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06 Nov 2014, at 01:10 , George Neville-Neil <gnn@neville-neil.com> = wrote: > On 5 Nov 2014, at 9:20, Alexander V. Chernikov wrote: >=20 >> On 05.11.2014 19:39, George Neville-Neil wrote: >>> Howdy, >>>=20 >>> 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. >>>=20 >>> In two weeks I will enable IPSec by default, again in preparation = for 11. >> Please don't. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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). >>=20 >> In contrast, I haven't seen IPSEC being able to process more than = 200kpps for any kind of workload. >>=20 >> 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. >>=20 >=20 > 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. I don=92t think making IPsec an pfil consumer is actually feasible but = that=92s a different story. > Also, if folks who know about these problems can send workloads and = test descriptions to the > list that would be very helpful. >=20 > Specific drivers and hardware types would be most helpful as this may = be device related > as well. >=20 > I will turn this on on some machines in the network test lab to see = what I can see. What you would want for the moment is a single read-mostly = (read-lockless, read-non-atomic) integer that tells you if you have any = policy in the system; that=92s for your branch statement. That=92s = probably the closest you can get to enabling it cheaply in GENERIC = without doing much. There=92s a tradeoff in that for a few packets the policy might not be = effective immediately but given the amount of time it takes to =93install=94= the policy thinking about any instant real-time guarantees here is not = feasible anyway. Just my 2cts. Bjoern
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?65C48D3B-0C08-4F8F-AF19-239238E49E62>