From: Phil Sutter <phil@xxxxxx> 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 <phil@xxxxxx> >> 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. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
