[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180219.100753.1512094681484399569.davem@davemloft.net>
Date: Mon, 19 Feb 2018 10:07:53 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: fw@...len.de
Cc: laforge@...monks.org, 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: Florian Westphal <fw@...len.de>
Date: Mon, 19 Feb 2018 15:53:14 +0100
> Sure, but looking at all the things that were added to iptables
> to alleviate some of the issues (ipset for instance) show that we need a
> meaningful re-design of how things work conceptually.
As you said iptables is in maintainenance mode.
But there are millions upon millions of users, like it or not, and
they aren't going away for decades. And this is the iptables binary
ABI I'm talking about, not the iptables user command line interface.
These discussions about nftables migrations sound like a person near a
power outage who exclaims: "What's the big deal, the lights are on in
my house?" Please see further than the view inside your home.
By in large, we are stuck with iptables's data path for an extremely
long time.
Major data centers doesn't even enable NFTABLES in their kernels, and
there is nothing you can do about that in the short to medium term.
Therefore, for all of the beneficial reasons I have discussed we
should make that datapath as aligned and integrated with our core
important technologies as possible, so that they can benefit from any
and all improvements in that area rather than just collecting dust.
Thank you.
Powered by blists - more mailing lists