From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shards.monkeyblade.net ([184.105.139.130]:34600 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753423AbeBSSlb (ORCPT ); Mon, 19 Feb 2018 13:41:31 -0500 Date: Mon, 19 Feb 2018 13:41:29 -0500 (EST) Message-Id: <20180219.134129.468159116056643040.davem@davemloft.net> To: phil@nwl.cc Cc: laforge@gnumonks.org, fw@strlen.de, daniel@iogearbox.net, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, alexei.starovoitov@gmail.com Subject: Re: [PATCH RFC 0/4] net: add bpfilter From: David Miller In-Reply-To: <20180219180551.GH15918@orbyte.nwl.cc> References: <20180219171411.GG15918@orbyte.nwl.cc> <20180219.122226.896334578399862770.davem@davemloft.net> <20180219180551.GH15918@orbyte.nwl.cc> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org List-ID: From: Phil Sutter Date: Mon, 19 Feb 2018 19:05:51 +0100 > Hi David, > > On Mon, Feb 19, 2018 at 12:22:26PM -0500, David Miller wrote: >> From: Phil Sutter >> Date: Mon, 19 Feb 2018 18:14:11 +0100 >> >> > OK, so reading between the lines you're saying that nftables project >> > has failed to provide an adequate successor to iptables? >> >> Whilst it is great that the atomic table update problem was solved, I >> think the emphasis on flexibility often at the expense of performance >> was a bad move. > > I don't see a lack of performance in nftables when being compared to > iptables (as we have now). From my point of view, it's quite the > contrary: nftables did a great job in picking up iptables performance > afterthoughts (e.g. ipset) and leveraging that to the max(TM) (verdict > maps, concatenated set entries). Assuming the virtual machine design > principle isn't just marketing but sets the course for JIT ruleset > optimizations, there's some margin as well. > > So from my perspective, one should say nftables increased flexibility > without sacrificing performance. I did not say nftables adjusted performance one way or another. It kept it on the same order of magnitude. And this is a design decision. > Yes, even with my limited experience I noticed that there is quite some > demand for even faster packet processing in Linux, mostly for rather > custom scenarios like forwarding into containers/VMs. Though my point > was about general purpose firewalling abilities in Linux, say people > securing their desktop or maintaining networks with less demands on > performance. I've always stated that low power, low end, systems are just a good place for high performance filtering as high end ones.