linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wolfgang Walter <linux@stwm.de>
To: netdev@vger.kernel.org
Cc: Florian Westphal <fw@strlen.de>,
	Steffen Klassert <steffen.klassert@secunet.com>,
	David Miller <davem@davemloft.net>,
	linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
	christophe.gouault@6wind.com,
	Greg KH <gregkh@linuxfoundation.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

  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 \
    --to=linux@stwm.de \
    --cc=christophe.gouault@6wind.com \
    --cc=davem@davemloft.net \
    --cc=fw@strlen.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    --cc=torvalds@linux-foundation.org \
    --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).