[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180219.103651.309290718144247274.davem@davemloft.net>
Date: Mon, 19 Feb 2018 10:36:51 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: laforge@...monks.org
Cc: 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
From: Harald Welte <laforge@...monks.org>
Date: Mon, 19 Feb 2018 16:23:21 +0100
>> Like it or not iptables ABI based filtering is going to be in the data
>> path for many years if not a decade or more to come.
>
> I beg to differ. For some people, yes. but then, as Florian points
> out, they can just as well use the existing x_tables kernel code. If
> they want something better, they can either replace their iptables
> program with xtables-compat from nftables, or whatever else might
> exist for eBPF support.
nftables has been proported as "better" for years, yet large
institutions did not migrate to it. In fact, they explicitly
disabled NFTABLES in their kernel config.
You may want to ponder for a little while why that might be.
I think netfilter is at a real crossroads right now.
In my opinion, any resistence to integration with eBPF and XDP will
lead to even less adoption of netfilter as a technology.
Therefore my plan is to move everything to be integrated around these
important core technologies. For the purposes of integration, code
coverage, performance, and the ability to juxtapose different bits of
eBPF code into larger optimized code streams that can also be
offloaded into hardware.
Powered by blists - more mailing lists