Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Wolfgang Walter <linux@stwm.de>
To:     Florian Westphal <fw@strlen.de>
Cc:     Steffen Klassert <steffen.klassert@secunet.com>,
        David Miller <davem@davemloft.net>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
        christophe.gouault@6wind.com
Subject: Re: Regression: kernel 4.14 an later very slow with many ipsec tunnels
Date:   Thu, 04 Oct 2018 15:57:52 +0200
Message-ID: <1729915.dWWxddREcQ@stwm.de>
User-Agent: KMail/4.14.3 (Linux/4.14.61-debian64.all+1.1; KDE/4.14.13; x86_64; ; )
In-Reply-To: <20181002213536.sgjansduqenps2md@breakpoint.cc>
References: <20180913135844.3ut6fxgx67t6ndtu@breakpoint.cc> <4327972.7bla238zOs@stwm.de> <20181002213536.sgjansduqenps2md@breakpoint.cc>
MIME-Version: 1.0
Content-Transfer-Encoding: 8BIT
Content-Type: text/plain; charset="iso-8859-1"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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