Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1614503imm; Tue, 2 Oct 2018 11:01:04 -0700 (PDT) X-Google-Smtp-Source: ACcGV60dFx2i7gAyg2pC4qnnGVfMFJSoC9SC4FwGSyJQ9sMLoieltxy9oUNqeUtHe2jO+rVFkXMq X-Received: by 2002:a62:8910:: with SMTP id v16-v6mr17299588pfd.106.1538503264252; Tue, 02 Oct 2018 11:01:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538503264; cv=none; d=google.com; s=arc-20160816; b=K+87qOur7Lzqmj3uNc5pNmrTc5dXPKiNmZJsYiVpchf9t74ewk+JjnhE8GWgo7EF4U DwYMurjo4ULNRkKVv8lT0vW0zRDJ0wQz3hVEnX8oJL4DiSstl2VLEKjnoY1HUvaKZh/y Hihg9XwWCiWiyp7SA248kJFSoFxdaX/Uy/fsdissfwFMEPEGA+HeOdIkyoq6WLy25jvF cA0BSTjv7h6QwQ8zDzgovDz3r40DRfSmUDbe2Swr44fEipcw/2F9AsiAD4eUxi0pwpkg a8wvrVhL4urbOXDQyWM63NK5c3d3ViGxr8jYMB0+nmgnIXYGVHg2IkzUY+jDVGcI7l8Z nISQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:user-agent:message-id:date:subject:cc:to :from; bh=R5t7yt2v8GC7E+mj27eytb/rQluOzCdztHqnixfAKl8=; b=a+gGVUFD6rbzTreMYFVe14RaKGkoU0qc6Jd6iOU2mc9tepS12ucDrx4dIXIlvGhr7G LhD2yyMGVas0kaPB4HRhIdXN3UOcH7pr+F6a8MDahJEom6hIOZd+aQ4Xnjg7P0M1rVDf us1XYGoGoS2W4O+1U9HZKiVmzh5UOWRJJUyL1nlNNslM5EPGFb3sQM1EdZ0HJ8e9ZNIz sBG1+esaGZaCji9lVbJuCJc3HAnNIyCV8vLeEQT4XNZGHCa5LzqKjE4SZ2y/HgxP09XG wRk9B3nTkrg7KVRShbZdYwCWLnS8Mum6+D+vtY8HwJzBzQNS3uk9mVLS+altwUIb3iO3 XITQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w18-v6si15726982ply.66.2018.10.02.11.00.49; Tue, 02 Oct 2018 11:01:04 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727537AbeJCASb convert rfc822-to-8bit (ORCPT + 99 others); Tue, 2 Oct 2018 20:18:31 -0400 Received: from dresden.studentenwerk.mhn.de ([141.84.225.229]:38736 "EHLO email.studentenwerk.mhn.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726657AbeJCASb (ORCPT ); Tue, 2 Oct 2018 20:18:31 -0400 Received: from mailhub.studentenwerk.mhn.de (mailhub.studentenwerk.mhn.de [127.0.0.1]) by email.studentenwerk.mhn.de (Postfix) with ESMTP id 42PmV03nqfzMkwT; Tue, 2 Oct 2018 19:34:00 +0200 (CEST) From: Wolfgang Walter To: Florian Westphal Cc: Steffen Klassert , David Miller , 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: Tue, 02 Oct 2018 19:34 +0200 Message-ID: <4327972.7bla238zOs@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: <20181002145616.pwdhbmafgsihbxvm@breakpoint.cc> References: <20180913135844.3ut6fxgx67t6ndtu@breakpoint.cc> <4708967.r5gU1pxIcW@stwm.de> <20181002145616.pwdhbmafgsihbxvm@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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 => A. 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 router. 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 10.0.0.0/16 <=> 10.1.0.0/29 encrypt .... 10.0.0.0/16 <=> 10.1.0.8/29 encrypt .... .... And things like that. 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. Here is the approach HiPAC took for packet classification https://pdfs.semanticscholar.org/a0bb/9d31e2499fb659c9e0d9544072d2f3c25079.pdf https://pdfs.semanticscholar.org/0dea/8ee87f596f200de2722cbe9480610dd1a0db.pdf Regards, -- Wolfgang Walter Studentenwerk M?nchen Anstalt des ?ffentlichen Rechts