From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Walter 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> References: <00000000000075fe86057ca6367e@google.com> <20181210124724.iuver2va3yjdsokf@breakpoint.cc> <20181210.095856.580441946779980596.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: David Miller , herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, steffen.klassert@secunet.com To: Florian Westphal Return-path: In-Reply-To: <20181210.095856.580441946779980596.davem@davemloft.net> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Am Montag, 10. Dezember 2018, 09:58:56 schrieb David Miller: > From: Florian Westphal > 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