From: Phil Sutter <phil@nwl.cc>
To: David Miller <davem@davemloft.net>
Cc: laforge@gnumonks.org, fw@strlen.de, daniel@iogearbox.net,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
alexei.starovoitov@gmail.com
Subject: Re: [PATCH RFC 0/4] net: add bpfilter
Date: Mon, 19 Feb 2018 19:05:51 +0100 [thread overview]
Message-ID: <20180219180551.GH15918@orbyte.nwl.cc> (raw)
In-Reply-To: <20180219.122226.896334578399862770.davem@davemloft.net>
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.
> Netfilter's chronic performance differential is why a lot of mindshare
> was lost to userspace networking technologies.
>
> Thankfully, we are gaining back a lot of that userbase with XDP and
> eBPF, thanks to the hard work of many individuals.
>
> To think that people are going to be willing to take the performance
> hit (whatever it's size) to go back to the "more flexible" nftables
> is really not a realistic expectation.
>
> And we have amassed enough interest and momentum that offloading eBPF
> in hardware on current and future hardware is happening.
>
> So I am going to direct us in directions that allow those realities to
> be taken advantage of, rather than pretending that this transition
> hasn't occurred already.
Hey, you secretly changed the topic! ;)
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 guess it will be a while until consumer hardware comes
with smart NICs (or they become affordable), so for those people
nftables is definitely a step forward.
Cheers, Phil
next prev parent reply other threads:[~2018-02-19 18:05 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-16 13:40 [PATCH RFC 0/4] net: add bpfilter Daniel Borkmann
2018-02-16 13:40 ` [PATCH RFC 1/4] modules: allow insmod load regular elf binaries Daniel Borkmann
2018-02-16 13:40 ` [PATCH RFC 2/4] bpf: introduce bpfilter commands Daniel Borkmann
2018-02-16 13:40 ` [PATCH RFC 3/4] net: initial bpfilter skeleton Daniel Borkmann
2018-02-16 13:40 ` [PATCH RFC 4/4] bpf: rough bpfilter codegen example hack Daniel Borkmann
2018-02-16 14:57 ` [PATCH RFC 0/4] net: add bpfilter Florian Westphal
2018-02-16 16:14 ` Florian Westphal
2018-02-16 20:44 ` Daniel Borkmann
2018-02-17 12:33 ` Harald Welte
2018-02-17 19:18 ` Florian Westphal
2018-02-16 22:33 ` David Miller
2018-02-17 12:21 ` Harald Welte
2018-02-17 20:10 ` Florian Westphal
2018-02-17 22:38 ` Florian Westphal
2018-02-16 16:53 ` Daniel Borkmann
2018-02-16 22:32 ` David Miller
2018-02-17 12:11 ` Harald Welte
2018-02-18 0:35 ` Florian Westphal
2018-02-19 12:03 ` Daniel Borkmann
2018-02-19 12:52 ` Harald Welte
2018-02-19 14:44 ` David Miller
2018-02-19 14:53 ` Florian Westphal
2018-02-19 15:07 ` David Miller
2018-02-19 15:20 ` Florian Westphal
2018-02-19 15:28 ` David Miller
2018-02-19 15:23 ` Harald Welte
2018-02-19 15:32 ` David Miller
2018-02-19 15:37 ` Jan Engelhardt
2018-02-19 15:43 ` David Miller
2018-02-19 15:36 ` David Miller
2018-02-19 17:20 ` Harald Welte
2018-02-19 17:29 ` David Miller
2018-02-19 18:37 ` Harald Welte
2018-02-19 18:47 ` David Miller
2018-02-19 17:40 ` Arturo Borrero Gonzalez
2018-02-19 18:06 ` Arturo Borrero Gonzalez
2018-02-19 18:43 ` David Miller
2018-02-19 15:00 ` David Miller
2018-02-19 14:59 ` Florian Westphal
2018-02-19 15:13 ` David Miller
2018-02-19 15:15 ` Florian Westphal
2018-02-19 15:27 ` David Miller
2018-02-19 15:38 ` Harald Welte
2018-02-19 15:44 ` David Miller
2018-02-19 17:14 ` Phil Sutter
2018-02-19 17:22 ` David Miller
2018-02-19 18:05 ` Phil Sutter [this message]
2018-02-19 18:41 ` David Miller
2018-02-19 20:41 ` Phil Sutter
2018-02-19 21:13 ` Florian Westphal
2018-02-20 10:44 ` Pablo Neira Ayuso
2018-02-20 14:07 ` Daniel Borkmann
2018-02-20 14:55 ` David Miller
2018-02-21 1:52 ` Alexei Starovoitov
2018-02-21 12:01 ` Pablo Neira Ayuso
2018-02-21 12:13 ` Florian Westphal
2018-02-22 2:20 ` nft/bpf interpreters and spectre2. Was: " Alexei Starovoitov
2018-02-22 11:39 ` Pablo Neira Ayuso
2018-02-22 17:06 ` Alexei Starovoitov
2018-02-22 18:47 ` Jann Horn
2018-02-19 17:41 ` Arturo Borrero Gonzalez
2018-02-19 21:30 ` Jozsef Kadlecsik
2018-02-19 15:27 ` Harald Welte
2018-02-19 15:31 ` David Miller
2018-02-19 17:09 ` Phil Sutter
2018-02-19 17:15 ` David Miller
2018-02-20 13:05 ` Phil Sutter
2018-02-20 9:35 ` Michal Kubecek
2018-02-20 18:10 ` Phil Sutter
2018-02-19 17:32 ` Harald Welte
2018-02-19 17:41 ` Arturo Borrero Gonzalez
2018-02-19 21:42 ` Willem de Bruijn
2018-02-18 23:35 ` Florian Westphal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180219180551.GH15918@orbyte.nwl.cc \
--to=phil@nwl.cc \
--cc=alexei.starovoitov@gmail.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=fw@strlen.de \
--cc=laforge@gnumonks.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).