Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1179116imm; Thu, 13 Sep 2018 14:05:09 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaUMHwxOliyBgn4x1X7i+yVCbZkRBny9zB06tLU8uuRm+0jZNSW/siGUAlMFUmbfPBUlA/V X-Received: by 2002:a63:3dc6:: with SMTP id k189-v6mr8680051pga.191.1536872709336; Thu, 13 Sep 2018 14:05:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536872709; cv=none; d=google.com; s=arc-20160816; b=iXn33ZMxsEpiED0Vv5ZufgltlSwEhXCyg9tcbwLTsrjSRkOWfuMeSPFPxG4jD65h3o x3CxUe0VY3mQ4aNwGnwRNh6mVd0Lqb5nse88iY7Mr+0sjGAjl4ECTFHiapIF7105VFhY C9OFr3URiUUdhm4aScUnSkPu/HunappgiWZqNQoL7IDOp8qZD6dZe2HBD4o/fQB+Mde9 vmY/l0yVI8MQ4E1naODHMQt/yCSF9BtxoWcaDAAiBohVxqWSOb6odyzMIPy5r/xRYwRu zzzmDt3nl8avL19mujfAdC4s3R4RPGZRRyfZ0qKwja+1Y57XFhJthth0yTatYeWDQwUL ZuhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=srUGrLmc4BwJ9EhtJNhPLEiZGqNgKs8r7eVngNflzug=; b=e+krl9rtIVc4a77idJNHnLCj9iE2Ln1mvbH6FsexHMxMM882OW7b5aj4Yf3IEeyf3/ BQYj5T0/WAlqBALiDpvrn5330dqyElx6Z1lTPxvU0Y/6muqWXDd0egwxwVUpNjFfRpNk o8C0DMj4tZbZJS3X3bnSRmGkkukpDVVlT+dtsMDxUatmRZTzTsIA2tmG6F5Yz1i+Tk2+ yPky4bukFx5QBmPq3YB3zVDVMe2nh70ChQv+NgGA9b1VC2bBIAtv3UmUEf3O+3bRIsb+ uEsZJ9GMivSJh5a4MhsxZbXsvWR8nPv7orYRPm7XuX0DnExg4YfSVjSJFXQGTtXxH45L jvzw== 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 p13-v6si5213291pgk.344.2018.09.13.14.04.53; Thu, 13 Sep 2018 14:05:09 -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 S1728177AbeINCOm (ORCPT + 99 others); Thu, 13 Sep 2018 22:14:42 -0400 Received: from Chamillionaire.breakpoint.cc ([146.0.238.67]:36658 "EHLO Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727383AbeINCOm (ORCPT ); Thu, 13 Sep 2018 22:14:42 -0400 Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.89) (envelope-from ) id 1g0Ylp-0001sy-NN; Thu, 13 Sep 2018 23:03:25 +0200 Date: Thu, 13 Sep 2018 23:03:25 +0200 From: Florian Westphal To: David Miller Cc: fw@strlen.de, linux@stwm.de, netdev@vger.kernel.org, steffen.klassert@secunet.com, 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 Message-ID: <20180913210325.5usfj2rorvuvtyc7@breakpoint.cc> References: <20180913135844.3ut6fxgx67t6ndtu@breakpoint.cc> <3448099.9yk84El3Sa@stwm.de> <20180913163848.ni5xc4gc4d6uusdn@breakpoint.cc> <20180913.102305.939671149040995911.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180913.102305.939671149040995911.davem@davemloft.net> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org David Miller wrote: > From: Florian Westphal > Date: Thu, 13 Sep 2018 18:38:48 +0200 > > > Wolfgang Walter wrote: > >> What I can say is that it depends mainly on number of policy rules and SA. > > > > Thats already a good hint, I guess we're hitting long hash chains in > > xfrm_policy_lookup_bytype(). > > I don't really see how recent changes can influence that. I don't think there is a recent change that did this. Walter says < 4.14 is ok, so this is likely related to flow cache removal. F.e. it looks like all prefixed policies end up in a linked list (net->xfrm.policy_inexact) and are not even in a hash table. I am staring at b58555f1767c9f4e330fcf168e4e753d2d9196e0 but can't figure out how to configure that away from the 'no hashing for prefixed policies' default or why we even have policy_inexact in first place :/ I'll look at this again tomorrow.