Re: [PATCH RFC 0/4] net: add bpfilter

[David Miller <davem@davemloft.net>]

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:
>> From: Phil Sutter <phil@nwl.cc>
>> 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.