Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Wolfgang Walter <linux@stwm.de>
To:     Florian Westphal <fw@strlen.de>
Cc:     David Miller <davem@davemloft.net>, herbert@gondor.apana.org.au,
        linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
        steffen.klassert@secunet.com
Subject: Re: INFO: rcu detected stall in xfrm_hash_rebuild
Date:   Fri, 14 Dec 2018 14:11:05 +0100
Message-ID: <2559562.n5nkmlqv4s@stwm.de>
User-Agent: KMail/4.14.3 (Linux/4.18.12-041812-generic; KDE/4.14.13; x86_64; ; )
In-Reply-To: <20181210.095856.580441946779980596.davem@davemloft.net>
References: <00000000000075fe86057ca6367e@google.com> <20181210124724.iuver2va3yjdsokf@breakpoint.cc> <20181210.095856.580441946779980596.davem@davemloft.net>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Am Montag, 10. Dezember 2018, 09:58:56 schrieb David Miller:
> From: Florian Westphal <fw@strlen.de>
> Date: Mon, 10 Dec 2018 13:47:24 +0100
>=20
> > After recent tree conversion, we could probably make the exact poli=
cies
> > part of the 'inexact tree' (which would be renamed to 'policy tree'=
 or
> > some such).
> >=20
> > Special-casing the exact policies made a lot of sense when we had
> > a single list for the inexact policies (to keep its length down).
> >=20
> > But now I think we could try to unify all of this and only maintain=

> > the existing tree-based storage.
> >=20
> > Would also remove the need to do lookups in two different
> > data structures (bydst-hash-then-inexact-tree).
> >=20
> > What do you think?
>=20
> I think this makes a lot of sense.

Sites mainly using tunnel mode this certainly makes sense.

I'm not so sure for transport mode. With transport mode the netmask usu=
ally is=20
/32 or /128, respectively (there may also be trap-rules). So a site onl=
y using=20
transport mode (road warrior scenario, for example) may see a large=20
performance regression if this is changed. They may do not have many en=
tries=20
in the inexact list if any at all.

Maybe there are a lot more transport mode users than tunnel mode users,=
 this=20
would explain why the removal of the flowcache did not hit that many pe=
ople.

We do not use transport mode, so I'm not familiar how strongswan for ex=
ample=20
handles that. I think that since 5.3 or so strongwans allows a catch ru=
le=20
(inexact) and then inserts exact policy rules on the fly. But I don't k=
now for=20
sure. There are a lot of tests on strongswan for different scenarios wh=
ich=20
also demonstrate how policy and state table finally will look like on a=
ll=20
hosts.

Here is one with such a scenario (transport mode trap policy on a gatew=
ay,=20
three road warriors):

https://www.strongswan.org/testing/testresults/ikev2/trap-any/

So I would try to find users who are heavy users of transport mode and =
see how=20
this change would impact there performance.

Regards,
--=20
Wolfgang Walter
Studentenwerk M=FCnchen
Anstalt des =F6ffentlichen Rechts