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 [thread overview]
Message-ID: <2559562.n5nkmlqv4s@stwm.de> (raw)
In-Reply-To: <20181210.095856.580441946779980596.davem@davemloft.net>
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
>
> > After recent tree conversion, we could probably make the exact policies
> > part of the 'inexact tree' (which would be renamed to 'policy tree' or
> > some such).
> >
> > 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).
> >
> > But now I think we could try to unify all of this and only maintain
> > the existing tree-based storage.
> >
> > Would also remove the need to do lookups in two different
> > data structures (bydst-hash-then-inexact-tree).
> >
> > What do you think?
>
> 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 usually is
/32 or /128, respectively (there may also be trap-rules). So a site only using
transport mode (road warrior scenario, for example) may see a large
performance regression if this is changed. They may do not have many entries
in the inexact list if any at all.
Maybe there are a lot more transport mode users than tunnel mode users, this
would explain why the removal of the flowcache did not hit that many people.
We do not use transport mode, so I'm not familiar how strongswan for example
handles that. I think that since 5.3 or so strongwans allows a catch rule
(inexact) and then inserts exact policy rules on the fly. But I don't know for
sure. There are a lot of tests on strongswan for different scenarios which
also demonstrate how policy and state table finally will look like on all
hosts.
Here is one with such a scenario (transport mode trap policy on a gateway,
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
this change would impact there performance.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
next prev parent reply other threads:[~2018-12-14 13:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-10 7:50 INFO: rcu detected stall in xfrm_hash_rebuild syzbot
2018-12-10 12:47 ` Florian Westphal
2018-12-10 17:58 ` David Miller
2018-12-14 13:11 ` Wolfgang Walter [this message]
2018-12-14 14:35 ` Florian Westphal
2018-12-14 14:56 ` Herbert Xu
2018-12-14 16:04 ` Christophe Gouault
2018-12-14 16:23 ` Florian Westphal
2018-12-14 16:28 ` Christophe Gouault
2018-12-14 19:07 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2559562.n5nkmlqv4s@stwm.de \
--to=linux@stwm.de \
--cc=davem@davemloft.net \
--cc=fw@strlen.de \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).