From: Phil Sutter <phil@nwl.cc>
Date: Mon, 19 Feb 2018 19:05:51 +0100
Hi David,
On Mon, Feb 19, 2018 at 12:22:26PM -0500, David Miller wrote:
quoted
From: Phil Sutter <phil@nwl.cc>
Date: Mon, 19 Feb 2018 18:14:11 +0100
quoted
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.