Hi,
On Wed, Jun 13, 2018 at 3:43 PM, Kristian Evensen
wrote:
> Thanks! I will prepare a firmware for one of my devices tonight, start
> testing tomorrow and report back when I have some results.
We have been testing this patch over the weekend and it has a
significant impact on performance. In o
Hi,
On Wed, Jun 13, 2018 at 2:40 PM, Florian Westphal wrote:
> Can you test attached patch?
>
> I'd like to see how much the pcpu cache helps or if it actually hurts
> in your setup.
>
> Subject: [TEST PATCH 4.14.y] xfrm: remove pcpu policy cache
>
> We need to re-evaluate if this still buys anyt
Kristian Evensen wrote:
> Hello,
>
> On Tue, Jul 18, 2017 at 8:15 PM, David Miller wrote:
> > Steffen, I know you have some level of trepidation about this because
> > there is obviously some performance cost immediately for removing this
> > DoS problem.
>
> In a project I am involved in, we a
Hello,
On Tue, Jul 18, 2017 at 8:15 PM, David Miller wrote:
> Steffen, I know you have some level of trepidation about this because
> there is obviously some performance cost immediately for removing this
> DoS problem.
In a project I am involved in, we are running ipsec (Strongswan) on
differen
From: Florian Westphal
Date: Mon, 17 Jul 2017 13:57:17 +0200
> After RCU-ification of ipsec packet path there are no major scalability
> issues anymore without flow cache.
>
> We still incur a performance hit, which comes mostly from the extra xfrm
> dst allocation/freeing.
> The last patch in t
After RCU-ification of ipsec packet path there are no major scalability
issues anymore without flow cache.
We still incur a performance hit, which comes mostly from the extra xfrm
dst allocation/freeing.
The last patch in the series adds a simple percpu cache to avoid the
extra allocation if a pac
