Thread (73 messages) flat view 73 messages, 13 authors, 2018-02-22

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 +0100
quoted
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.
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help