Received: by 10.223.185.111 with SMTP id b44csp468996wrg; Fri, 9 Mar 2018 07:58:46 -0800 (PST) X-Google-Smtp-Source: AG47ELt/gJqcsV89SP4DHNIDMiuVc13m8I/jeYtJ5om9FydtEPY8yWKSf7lTv+/Pbv1MCTWTSHTG X-Received: by 2002:a17:902:66e6:: with SMTP id e93-v6mr28301062plk.312.1520611126605; Fri, 09 Mar 2018 07:58:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520611126; cv=none; d=google.com; s=arc-20160816; b=N/1T+OSIP70ouXP6M2eMzheBWmS+SOWb2oBFq2QaME441kDC9So5LqErDeuILglOHi zWbcUALxOwiMKoaG7igALDPsHULthYb7QZd18qP8KKqjWq0xcaTqDtR5SfWmwHo0+O24 gQ1TM2JSxJ5Jx5rItP9A92D1fm4Qtfpe6HiyIMs1+Gp1E76taXiaWqmnfcVawBQHrdAJ ALKyBx4d8LyHMEvOiiJVapHqxHu/YR/MH20oyprT5oC3UQi3kCCO+e8WLTF6k362VHxM c/oU3TjvkQ24WTmbrtZu+70E0YSr0zs234YCM0IWWKx/A/TAILStDTvnS0by7EWnbLse GDDA== 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 :arc-authentication-results; bh=9ZMk2lqHQ+4InMgPnc8ycpWVqG1X/QQ+riQ+Fas7s/s=; b=HxxRuLSnJkiJFd1NjQ37SOJEFoHqqs2muLhh2m9w26YrhgsFQTBQfgPnnDQLR/dkSv 0T2rx/1ZQc+u3Ct/imWBWzdbQC7hOAjOp5q8cqW0cbpS6Y8g1cLgyqSnWKkLB+rI6H+G dC2dNbRziU47NIuFWIS5JQeYD18AGIWPNsqOa4mAyPR90aUY3t4nVm5RC/xaHODv91OJ EOWf92qofsjzKn5IAL+pmeDy+IRZeojve+nbsr4/jHXxN+ypqtYdCkOiK9R5R2hWir/j R8z7J59d8j6E4pU2Q0v7A0xQEuoIdabCJgPknWoOi3BKQS9tuAYR5bFLrmTUwrpIFMxa e+Gg== 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 v6si897056pgq.146.2018.03.09.07.58.31; Fri, 09 Mar 2018 07:58:46 -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 S932087AbeCIP5a (ORCPT + 99 others); Fri, 9 Mar 2018 10:57:30 -0500 Received: from shards.monkeyblade.net ([184.105.139.130]:52972 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751122AbeCIP53 (ORCPT ); Fri, 9 Mar 2018 10:57:29 -0500 Received: from localhost (67.110.78.66.ptr.us.xo.net [67.110.78.66]) (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 C68E010947B65; Fri, 9 Mar 2018 07:57:27 -0800 (PST) Date: Fri, 09 Mar 2018 10:57:24 -0500 (EST) Message-Id: <20180309.105724.519703919967625754.davem@davemloft.net> To: dwmw2@infradead.org Cc: fw@strlen.de, pablo@netfilter.org, rga@amazon.de, bridge@lists.linux-foundation.org, stephen@networkplumber.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, aliguori@amazon.com, nbd@openwrt.org Subject: Re: [RFC PATCH v2] bridge: make it possible for packets to traverse the bridge without hitting netfilter From: David Miller In-Reply-To: <1520609475.17937.42.camel@infradead.org> References: <20150306142932.GA15926@salvia> <20150306163700.GC20382@breakpoint.cc> <1520609475.17937.42.camel@infradead.org> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) 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, 09 Mar 2018 07:57:28 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: David Woodhouse Date: Fri, 09 Mar 2018 15:31:15 +0000 > Eschewing a 15% speedup on the basis that "well, even though we've had > three of these already for a decade, we're worried that adding a fourth > might open the floodgates to further patches" does seem a little odd to > me, FWIW. The cost we are dealing with is a fundamental one which is a result of the hook design. Indirect calls are killer. Indirect calls are even more killer now in the age of Spectre and retpolines. I definitely would rather see the fundamental issue addressed rather than poking at it randomly with knobs for this case and that. Thank you.