From: Florian Westphal <fw@strlen.de>
To: David Miller <davem@davemloft.net>
Cc: fw@strlen.de, linux@stwm.de, netdev@vger.kernel.org,
steffen.klassert@secunet.com, linux-kernel@vger.kernel.org,
torvalds@linux-foundation.org, christophe.gouault@6wind.com
Subject: Re: Regression: kernel 4.14 an later very slow with many ipsec tunnels
Date: Thu, 13 Sep 2018 23:03:25 +0200 [thread overview]
Message-ID: <20180913210325.5usfj2rorvuvtyc7@breakpoint.cc> (raw)
In-Reply-To: <20180913.102305.939671149040995911.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
> From: Florian Westphal <fw@strlen.de>
> Date: Thu, 13 Sep 2018 18:38:48 +0200
>
> > Wolfgang Walter <linux@stwm.de> wrote:
> >> What I can say is that it depends mainly on number of policy rules and SA.
> >
> > Thats already a good hint, I guess we're hitting long hash chains in
> > xfrm_policy_lookup_bytype().
>
> I don't really see how recent changes can influence that.
I don't think there is a recent change that did this.
Walter says < 4.14 is ok, so this is likely related to flow cache removal.
F.e. it looks like all prefixed policies end up in a linked list
(net->xfrm.policy_inexact) and are not even in a hash table.
I am staring at b58555f1767c9f4e330fcf168e4e753d2d9196e0
but can't figure out how to configure that away from the
'no hashing for prefixed policies' default or why we even have
policy_inexact in first place :/
I'll look at this again tomorrow.
next prev parent reply other threads:[~2018-09-13 21:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-13 11:30 Regression: kernel 4.14 an later very slow with many ipsec tunnels Wolfgang Walter
2018-09-13 13:58 ` Florian Westphal
2018-09-13 15:46 ` Wolfgang Walter
2018-09-13 16:38 ` Florian Westphal
2018-09-13 17:23 ` David Miller
2018-09-13 21:03 ` Florian Westphal [this message]
2018-09-13 21:12 ` David Miller
2018-09-14 5:06 ` Steffen Klassert
2018-09-14 5:54 ` Florian Westphal
2018-09-14 6:01 ` Steffen Klassert
2018-09-14 8:01 ` Christophe Gouault
2018-09-14 11:49 ` Wolfgang Walter
2018-10-02 14:45 ` Wolfgang Walter
2018-10-02 14:56 ` Florian Westphal
2018-10-02 17:34 ` Wolfgang Walter
2018-10-02 21:35 ` Florian Westphal
2018-10-04 13:57 ` Wolfgang Walter
2018-10-25 9:38 ` Wolfgang Walter
2018-10-25 17:34 ` David Miller
2018-10-25 19:24 ` Florian Westphal
2018-10-26 12:18 ` Wolfgang Walter
2018-10-25 22:45 ` Florian Westphal
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=20180913210325.5usfj2rorvuvtyc7@breakpoint.cc \
--to=fw@strlen.de \
--cc=christophe.gouault@6wind.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@stwm.de \
--cc=netdev@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.