lkml.org 
[lkml]   [2018]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Regression: kernel 4.14 an later very slow with many ipsec tunnels
Date
Am Dienstag, 2. Oktober 2018, 23:35:36 schrieb Florian Westphal:
> Wolfgang Walter <linux@stwm.de> wrote:
> > Am Dienstag, 2. Oktober 2018, 16:56:16 schrieb Florian Westphal:
> > > I'm experimenting with per-dst inexact lists in an rbtree but
> > > this will take time.
> >
> > Hmm, I doubt that this is worth the effort. And certainly not that easy
>
> 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.

>
> I see no reason why we can't have inexact lists done per dst<->src pairs.
>
> > You may have a lot of rules of the form say
> >
> > 10.0.0.0/16 <=> 10.1.0.0/29 encrypt ....
> > 10.0.0.0/16 <=> 10.1.0.8/29 encrypt ....
>

<=> means (in the forwarding case) that the rule set contains the inverted
rule (at least if you use it in usually ways). So

10.0.0.0/16 <=> 10.1.0.0/29 encrypt ....

means

10.0.0.0/16 => 10.1.0.0/29
10.1.0.0/29 => 10.0.0.0/16

> Sure.
>
> > Also, you get something like that
> >
> > 10.0.1.0/24 <=> 10.0.2.0/29 allow
> > 10.0.0.0/16 <=> 10.0.2.0/24 encrypt
> > 0.0.0.0 <=> 10.0.2.0/16 block
> >
> > And people may use source port and/or destination port or protocol
> > (tcp/udp/imcp) to further tailor there ruleset.
>
> Yes. 0.0.0.0/0 handling will require some extra consideration.
>

There may also be rulesets like

10.0.1.0/24 => 10.1.0.0/29 encrypt X
10.0.0.0/16 => 10.1.0.0/29 encrypt Y

Or

10.0.0.0/16 * => 10.1.0.0/24 80 encrypt Y
10.0.1.0/24 * => 10.1.0.0/17 * encrypt X
10.0.0.0/16 * => 10.1.0.0/20 * encrypt Z

> So far I have not seen a show-stopper however.

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,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

\
 
 \ /
  Last update: 2018-10-04 15:58    [W:0.078 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site