[lkml]   [2018]   [Oct]   [2]   [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, 16:56:16 schrieb Florian Westphal:
> Wolfgang Walter <> wrote:
> > Since my last reply to this message I didn't get a reply: is there any
> > progress how to fix this performance regression I missed?
> Did you test/experiment with hthresh config option?

I did. It did not improve the situation.

I suppose that is because our masks range from /16 to /30 and excpecially have
for example /16 <=> /8 and vice versa.

When forwarding, every policy A => B also implies that you add a policy B =>

I'm not familiar when the policy database is consulted, but I think it now has
to for every not encrypted paket, and for those all rules have to be
consulted. And unencrypted traffic is a large part of the traffic on that

That is: for unencrypted traffic neither the buckets of the hash nor the
inexact list may be large.

> > Or are we stuck here with longterm kernel 4.9 for a long time?
> 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
correctly done, as it still would have to obey the original order of the rules
(their priority).

You may have a lot of rules of the form say <=> encrypt .... <=> encrypt ....

And things like that.

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.

Here is the approach HiPAC took for packet classification

Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

 \ /
  Last update: 2018-10-02 19:35    [W:3.268 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site