Date: Wed, 5 Nov 2014 17:37:51 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: George Neville-Neil <gnn@neville-neil.com> Cc: "Andrey V. Elsukov" <ae@FreeBSD.org>, "Alexander V. Chernikov" <melifaro@FreeBSD.org>, net@FreeBSD.org Subject: Re: IPSEC in GENERIC [was: Re: netmap in GENERIC, by default, on HEAD] Message-ID: <20141106013751.GJ8852@funkthat.com> 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
George Neville-Neil wrote this message on Wed, Nov 05, 2014 at 17:10 -0800:
> 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.
In this workload, how many associtations are you testing? If you're
testing more than a few, see the end of my email for more info..
> >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.
Yes, also, a good description of how to manually set IPsec keys for
testing would be good... I haven't had any luck in my testing... and
I keep getting:
ipsec4_common_input_cb: cannot handle inner ip proto 50
which doesn't make sense, as it should be able to handle ESP...
> 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.
I have a patch that uses atomics instead of locks for some of the ref
counting, but I belive it may suffer from the problem of not having a
ref count held by the table, so I'm not sure it's ready for prime
time, but it does significantly increase the PPS rate...
If we are going to go high PPS and full SMP, it'll definately need a
lot of work to segment lookups and the like...
Also, sptree isn't a tree, it's a LIST.. The same goes for sahtree...
So, if you have more than about 5 SP or SAH's, then obviously you'll
have lots of fun...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141106013751.GJ8852>