From: Harald Welte <lafo...@gnumonks.org> Date: Mon, 19 Feb 2018 13:52:18 +0100
>> Right, having a custom iptables, libiptc or LD_PRELOAD approach would work >> as well of course, but it still wouldn't address applications that have >> their own custom libs programmed against iptables uapi directly or those >> that reused a builtin or modified libiptc directly in their application. > > 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. 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. Therefore it behooves us to accept this reality and align the data path generated to match what the rest of the kernel is moving towards and that is eBPF and XDP. Furthrmore, on a long term maintainence perspective, it means that every data path used by the kernel for iptables will be fully verified by the eBPF verifier. This means that the iptables data path will be guaranteed to never get into a loop, access out of bounds data, etc. That to me is real power, and something we should pursue. This doesn't even get into the offloading and other benefits that are possible. I know you can't see how offloading is possible, but I hope are some further discussion you can see how that might work. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
