From: Wolfgang Walter <firstname.lastname@example.org> To: email@example.com Cc: Florian Westphal <firstname.lastname@example.org>, Steffen Klassert <email@example.com>, David Miller <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, Greg KH <firstname.lastname@example.org> Subject: Re: Regression: kernel 4.14 an later very slow with many ipsec tunnels Date: Thu, 25 Oct 2018 11:38:19 +0200 [thread overview] Message-ID: <2766296.15tpkxTHJV@stwm.de> (raw) In-Reply-To: <1729915.dWWxddREcQ@stwm.de> Hello, there is now a new 4.19 which still has the big performance regression when many ipsec tunnels are configured (throughput and latency get worse by 10 to 50 times) which makes any kernel > 4.9 unusable for our routers. I still don't understand why a revert of the flow cache removal at least for the longterm kernels is that a bad option (maybe as a compile time option), especially as there is no workaround available. We use linux in that scenario since more than 10 years so I'm really rather unhappy if not to say despaired that we will be stucked with 4.9 for an unforeseeable future. We would have detected and reported that performance regression much earlier if not another bug in ipsec had prevented us from running 4.14 and later until end of august 2018 (See kernels > v4.12 oops/crash with ipsec-traffic: bisected to b838d5e1c5b6e57b10ec8af2268824041e3ea911: ipv4: mark DST_NOGC and remove the operation of dst_free()). Am Donnerstag, 4. Oktober 2018, 15:57:52 schrieb Wolfgang Walter: > Am Dienstag, 2. Oktober 2018, 23:35:36 schrieb Florian Westphal: [snip] > > Well, I'm not going to send a revert of the flowcache removal. > > > > > > I'm willing to experiment with alternatives to a full iteration of the > > inexact list but thats it. > > If this brings performance back to pre-removal, I'm fine with that. I'm even > fine if it is slower by a factor of 2. > > I think it is a serious regression, and there is no workaround, and therefor > it cannot stay like that. > > So I still hope that reverting is an option if no acceptable solution can be > found. > > > > correctly done, as it still would have to obey the original order of the > > > rules (their priority). > > > > Except that neither the priority or the order in which it was added > > matters in case the selector doesn't match. > > To match a packet one has to find all matching rules and chose that one with > the lowest priority. > > "indexing" by dst will not help much if you have a ruleset where a lot of > rules sharing a dst. You also have to replicate rules with dsts that have a > prefix oft another dst as they may habe a higher priority even if they are > less specific. > > Every such entry may again have such an "indexing" by dst. Only then this > would be efficient. > [snip] > > I wonder why there is no such thing for netfilter or the rules list in > routing. nf does not have such a thing, either. This is the reason why I > think that this is not that easy and for longterm kernel 4.14 the best > solution will be a revert anyway. > > Regards, Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts
next prev parent reply other threads:[~2018-10-25 9:38 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-09-13 11:30 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 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 [this message] 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=2766296.15tpkxTHJV@stwm.de \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Regression: kernel 4.14 an later very slow with many ipsec tunnels' \ /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
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).