Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2447134imu; Fri, 14 Dec 2018 11:08:40 -0800 (PST) X-Google-Smtp-Source: AFSGD/Wh5+3SZwtkkDWcvuqJYbk4wOOtRRLrwYsmETUMGEiedUDB072OQxESVCkBF/rD1o9iaFc3 X-Received: by 2002:a63:5455:: with SMTP id e21mr3799008pgm.316.1544814520244; Fri, 14 Dec 2018 11:08:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544814520; cv=none; d=google.com; s=arc-20160816; b=K9p3eVfCLCnt8MMA0mst/+L3xgEYqOsU1BRnDhsYnNMteq/8ulpWnae5IP5dVAHix/ TRghM5J4CvyaRXLBWNDoht7yeQIKYn96gUSjyEtZ7bSCL8XkhH4zWHLLBJDUfEPumfIq sVZh1mWrMLFsjuRXlMMDKzPS4TFnJ198tD28rtBQBiZBg1I5gX5YyeiMv+wTHEnIdsdR WQ39c5ysfYkltmSU+E0iuTEXzR+X83N1go8V+ZPgTwbNt8RuwxFpOobzxCH/jWi2FRNW Co5phZfxsp6NoXTmmBjvbi36NfVyBI6ufo+RXU0Kd/dYZHMMFUoJ3GpSPYJ5KyasKspK YjGg== 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:from:subject:cc:to:message-id:date; bh=W2O2xFIZZrf+gq/YWcl5acCKOnCj9M3FJ1SWRrcwGok=; b=U59YK96Qwpn4+3LqgBEqPWDBZiOEkHfC2LJDBu3iXslWSJTXFQRYXTw92nU9qqe9Tg vdk+jIKGgtTIhaAKFe2Obfb8u85X1y9jEXakBMTvBFwHdO1V9hqDuS62MqA5OjihgPmf C9EK4q2kSZM56p7OLcl2cp1rLgpdqDeK/Ma406vvwTbRr5Gr7mGq/jezcX5Z80rRJZYi 05yvkXfaXjNc0YTEnyV0wzTYjsPM1nv22SOboeSQnUILfISfSGteebCygTWHm+EJAkV3 GrttxT1pDzJMw6XbSXAh/O1ANK/l1EVjnsVmlkL3Gg4PEXH33qhdD78r33mb9RZt1jzT cfYg== 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 x186si4678950pfx.269.2018.12.14.11.08.25; Fri, 14 Dec 2018 11:08:40 -0800 (PST) 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 S1730669AbeLNTHG (ORCPT + 99 others); Fri, 14 Dec 2018 14:07:06 -0500 Received: from shards.monkeyblade.net ([23.128.96.9]:59346 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730410AbeLNTHG (ORCPT ); Fri, 14 Dec 2018 14:07:06 -0500 Received: from localhost (unknown [IPv6:2601:601:9f80:35cd::bf5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 0C21E14DE5F41; Fri, 14 Dec 2018 11:07:06 -0800 (PST) Date: Fri, 14 Dec 2018 11:07:05 -0800 (PST) Message-Id: <20181214.110705.1283167545212637328.davem@davemloft.net> To: fw@strlen.de Cc: christophe.gouault@6wind.com, linux@stwm.de, herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, steffen.klassert@secunet.com Subject: Re: INFO: rcu detected stall in xfrm_hash_rebuild From: David Miller In-Reply-To: <20181214162333.utlut746n3butkuf@breakpoint.cc> References: <20181214143532.43zgy2hwkdskwfn2@breakpoint.cc> <20181214162333.utlut746n3butkuf@breakpoint.cc> X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 14 Dec 2018 11:07:06 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Florian Westphal Date: Fri, 14 Dec 2018 17:23:33 +0100 > Christophe Gouault wrote: >> The main use cases I have encountered and tried to address with the >> hash-based lookup were network operator use cases: >> - a lot of dynamic /32 <=> /32 policies (protecting GTP tunnels) >> - or a lot of dynamic policies with the same prefix lengths (e.g. /16 <=> /24) >> and a few non-hashed policies stored in the linked list. > > Thanks for the detailed information. > > [..] > >> Could you verify how the configuration time would behave in such use >> cases if the hash-based lookup was replaced by a tree-based lookup? > > I won't send a patch to remove your work, at least not at this time. > > In case I'd do this removal (thresholds, hash table, or both) > i will make these tests to see how large the impact is. Florian, thanks for working so hard on this. The operational feedback is absolutely essential for figuring out how to move forward on this issue, otherwise we'll just keep going back and forth on the approach.