Message-ID: <20180220104431.xsrfvdaqbw6uxmwt@salvia>
Date:   Tue, 20 Feb 2018 11:44:31 +0100
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     David Miller <davem@...emloft.net>
Cc:     phil@....cc, laforge@...monks.org, fw@...len.de,
        daniel@...earbox.net, netdev@...r.kernel.org,
        netfilter-devel@...r.kernel.org, alexei.starovoitov@...il.com
Subject: Re: [PATCH RFC 0/4] net: add bpfilter

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!

Powered by blists - more mailing lists