Hi David! On Mon, Feb 19, 2018 at 12:22:26PM -0500, David Miller wrote: [...] > Netfilter's chronic performance differential is why a lot of mindshare > was lost to userspace networking technologies. Claiming that Netfilter is the reason for the massive adoption of userspace networking isn't a fair statement at all. Let's talk about performance if this is what you want: * Our benchmarks here are delivering ~x9.5 performance boost for IPv4 load balancing from netfilter ingress. * ~x2 faster than iptables prerouting when dropping packets at very early stage in the network datapath - dos attack scenario - again from the ingress hook. * The new flowtable infrastructure that will show up in 4.16 provides a faster forwarding path, measuring ~x2 faster forwarding here, _by simply adding one single rule to your FORWARD chain_. And that's just the initial implementation that got merged upstream, we have room to fly even faster. And that's just the beginning, we have more ongoing work, incrementally based on top of what we have, to provide even faster datapath paths with very simple configurations. Note that those numbers above are very similar numbers to what we have seen in bpf. Well, to be honest, we're just slightly behind bpf, since benchmarks I have seen on loading balancing IPv4 is x10 from XDP, dropping packets also slightly more than x2, which is actually happening way earlier than ingress, naturally dropping earlier gives us better numbers. But it's not all about performance... let's have a look at the "iron triangle"... We keep usability in our radar, that's paramount for us. Netfilter is probably so much widely more adopted than tc because of this. The kind of problems that big Silicon datacenters have to face are simply different to the millions of devices running Linux outthere, there are plenty of smart devops outthere that sacrify the little performance loss at the cost of keeping it easy to configure and maintain things. If we want to talk about problems... Every project has its own subset of problems. In that sense, anyone that has spent time playing with the bpf infrastructure is very much aware of all of its usability problems: * You have to disable optimizations in llvm, otherwise the verifier gets confused too smart compiler optimizations and rejects the code. * Very hard to debug the reason why the verifier is rejecting apparently valid code. That results in people playing strange "moving code around up and down". * Lack of sufficient abstraction: bpf is not only exposing its own software bugs through its interface, but it will also bite the dust with CPU bugs due to lack of glue code to hide details behind the syscall interface curtain. That will need a kernel upgrade after all to fix, so all benefits of adding new programs. We've even seem claims on performance being more important than security in this mailing list. Don't get me wrong, no software is safe from security issues, but if you don't abstract your resources in the right way, you have more chance to have experimence more problems. Just to mention a few of them. So, please, let's focus each of us in our own work. Let me remind your wise words - I think just one year ago in another of these episodes of the bpf vs. netfilter: "We're all working to achieve the same goals", even if we're working on competing projects inside Linux. Thanks! -- 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
