Thread (73 messages) flat view 73 messages, 13 authors, 2018-02-22

Re: [PATCH RFC 0/4] net: add bpfilter

From: Florian Westphal <fw@strlen.de>
Date: 2018-02-19 14:56:46

David Miller [off-list ref] wrote:
quoted
How many of those wide-spread applications are you aware of?  The two
projects you have pointed out (docker and kubernetes) don't. As the
assumption that many such tools would need to be supported drives a lot
of the design decisions, I would argue one needs a solid empircal basis.
I see talk about "just replacing the iptables binary".

A long time ago in a galaxy far far away, that would be a reasonable
scheme.  But that kind of approach won't work in the realities of
today.

You aren't going to be able to replace the iptables binary in the tens
of thousands of container images out there, nor the virtualization
installations either.
Why would you have to?
iptables kernel parts are still maintained, its not dead code that
stands in the way.

We can leave it alone, in maintenance mode, just fine.
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.  iptables is a
victim of it's own success, like it or not :-) Yes, the ABI is
terrible, but obviously it was useful enough for lots of people.
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.

The umh helper translation that has been proposed could be applied to
transparently xlate iptables to nftables (or e.g. iptables compat32 to
iptables64), i.e. legacy binary talks to kernel, kernel invokes umh, umh
generates nftables netlink messages).

But I don't even see a need to do this, I don't think its an issue
to leave it in the tree even for another decade or more if needed be.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help