Received: by 2002:ac0:aa62:0:0:0:0:0 with SMTP id w31-v6csp1650075ima; Thu, 25 Oct 2018 02:39:10 -0700 (PDT) X-Google-Smtp-Source: AJdET5crcMI9PoVnTIVSUxPIUm3o0wa4fJp9V6sdKTPm7QlTST9tWGhkb99ISjfrqfUj9DAzDnwt X-Received: by 2002:a17:902:503:: with SMTP id 3-v6mr786747plf.252.1540460350069; Thu, 25 Oct 2018 02:39:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540460350; cv=none; d=google.com; s=arc-20160816; b=n2UVbrcR1eUA21LVljti8EO7rKENanGwSSJFbvT5MRAy7ikDAldU8solmZiBxRZgU6 /Gluzysc8sCXvjRlKioWmVNyShSI/WyjLBn+qr0SDqncYaJlQwoU4FjQjOEn/aLa04bX KC0iKZ35q3o7jFuOtVVQv/KyBIE9/mVnArvrcVNku1x3xpYdMR5S3jqGVPZn9AwoKcf7 9/NOyoIGqOVE1dQt2rvTIuDoefU1Kd9YK+En0h74YbnRtj+n6gALMuzbR1FrF1e1BQ2k 9DZ+kF5d2CamxLSZWwgSsVrf44HRDDfBI0kjS5cFsFyXXXkPAQ7HwbzNKQ7pKcL9UEWG qJKQ== 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=s/lCMWGrwTZI45LV89jZbjB6oht7qKkJHNsKxhKCr7s=; b=R+GNXPYk8y2fh9Y/5K5AUMUY8ZwPPzVzIju58qgR0WeYGRGUfDcD93vNiL7A/SOsLH 4Z4yRXqokGvPv4I9vIjHho+x1Ovtip3Bf1UyYcCwMtKl+wsUlGC3BYYe78t+LbKUgvN1 9f7TiYhvRy1nyNSGy+MbHsJc74C23/9mjClBDOARvbXuSaFXpoKg10iYkINPrwUWU70+ U5KTzJh8lSuKZv+1mbQx60SPIfT8eUyCf8a4UeSds78v2xb5DgPbC6tGHuthIDvWqzsJ BtCapLQ5mWOSkkGpcDOFb5qDvKePEl+GXPFPrhG5lp6+aqZWd3hEURjeHhdTFGkX7p81 6osw== 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 e2-v6si7808792pgc.233.2018.10.25.02.38.54; Thu, 25 Oct 2018 02:39:10 -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 S1727021AbeJYSKS convert rfc822-to-8bit (ORCPT + 99 others); Thu, 25 Oct 2018 14:10:18 -0400 Received: from dresden.studentenwerk.mhn.de ([141.84.225.229]:35704 "EHLO email.studentenwerk.mhn.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726652AbeJYSKR (ORCPT ); Thu, 25 Oct 2018 14:10:17 -0400 Received: from mailhub.studentenwerk.mhn.de (mailhub.studentenwerk.mhn.de [127.0.0.1]) by email.studentenwerk.mhn.de (Postfix) with ESMTP id 42ghrW6RFMzMkwB; Thu, 25 Oct 2018 11:38:19 +0200 (CEST) From: Wolfgang Walter To: netdev@vger.kernel.org Cc: Florian Westphal , Steffen Klassert , David Miller , linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, christophe.gouault@6wind.com, Greg KH Subject: Re: Regression: kernel 4.14 an later very slow with many ipsec tunnels Date: Thu, 25 Oct 2018 11:38:19 +0200 Message-ID: <2766296.15tpkxTHJV@stwm.de> User-Agent: KMail/4.14.3 (Linux/4.18.12-041812-generic; KDE/4.14.13; x86_64; ; ) In-Reply-To: <1729915.dWWxddREcQ@stwm.de> References: <20180913135844.3ut6fxgx67t6ndtu@breakpoint.cc> <20181002213536.sgjansduqenps2md@breakpoint.cc> <1729915.dWWxddREcQ@stwm.de> 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 Hello, there is now a new 4.19 which still has the big performance regression when many ipsec tunnels are configured (throughput and latency get worse by 10 to 50 times) which makes any kernel > 4.9 unusable for our routers. I still don't understand why a revert of the flow cache removal at least for the longterm kernels is that a bad option (maybe as a compile time option), especially as there is no workaround available. We use linux in that scenario since more than 10 years so I'm really rather unhappy if not to say despaired that we will be stucked with 4.9 for an unforeseeable future. We would have detected and reported that performance regression much earlier if not another bug in ipsec had prevented us from running 4.14 and later until end of august 2018 (See kernels > v4.12 oops/crash with ipsec-traffic: bisected to b838d5e1c5b6e57b10ec8af2268824041e3ea911: ipv4: mark DST_NOGC and remove the operation of dst_free()). Am Donnerstag, 4. Oktober 2018, 15:57:52 schrieb Wolfgang Walter: > Am Dienstag, 2. Oktober 2018, 23:35:36 schrieb Florian Westphal: [snip] > > 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. > [snip] > > 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, Regards, -- Wolfgang Walter Studentenwerk M?nchen Anstalt des ?ffentlichen Rechts