Re: [PATCH RFC 0/4] net: add bpfilter
From: Phil Sutter <phil@nwl.cc>
Date: 2018-02-19 20:41:26
Hi David, On Mon, Feb 19, 2018 at 01:41:29PM -0500, David Miller wrote:
From: Phil Sutter <phil@nwl.cc> Date: Mon, 19 Feb 2018 19:05:51 +0100quoted
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 +0100quoted
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.
Oh, seems I missed your point then. What subject did you have in mind when you wrote "emphasis on flexibility often at the expense of performance"? I thought you were talking about nftables.
quoted
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.
Do you think these systems are likely to receive a NIC (or some sort of co-processor) which allows for offloading eBPF to? Maybe I miss the point again, but this is the only argument for bpfilter over nftables - and that only if one ignores the option to implement an eBPF backend for nftables VM). OK, maybe this clarifies once I know what you had in mind when you wrote that reply. Cheers, Phil