[lkml]   [2018]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Regression: kernel 4.14 an later very slow with many ipsec tunnels
Am Dienstag, 2. Oktober 2018, 23:35:36 schrieb Florian Westphal:
> Wolfgang Walter <> 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

> > 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
> >
> > <=> encrypt ....
> > <=> encrypt ....

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

means => =>

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

There may also be rulesets like => encrypt X => encrypt Y

Or * => 80 encrypt Y * => * encrypt X * => * 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.

Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

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