Messages in this thread |  | | From | Wolfgang Walter <> | Subject | Re: Regression: kernel 4.14 an later very slow with many ipsec tunnels | Date | Thu, 04 Oct 2018 15:57:52 +0200 |
| |
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
|  |