Nftables: Not addressing VJ channels or userspace tcp

Sounds like nftables is a technical improvement on iptables. The networking stack could do with a few technical improvements. Yes, there is a lot of duplication in the various xxxtables implementations. But then there is a lot of overlap between xxxtables and netfilter itself. And not a small amount of overlap between the functions provided by xxxtables, xxxfilter and the routing tables. You can, for example, use any one of them to drop a packet. If what Patrick has done addresses the duplication all the way down the stack, then it is a huge improvement.

Out of the 3 of them, iptables is probably the least efficient way of doing things since it provides no form of table lookup. Thus you get one linear list of rules which always takes O(n) to process. The others can do table lookups. So iptables it makes sense to replace iptables. But ....

Almost everyone uses iptables to get the job done? Why. Documentation. Rusty's user level documentation for ipchanins and later iptables on the other hand is possibly the best of any kernel documentation I have seen. It sets the standard, and is a fine example others should follow.

The netfilter developers on the other hand have an appalling record for doing documentation. It lies at the other end of the spectrum - possibly the worst documentation for any kernel tool. This tradition started with Alexy, who didn't bother to write a single line of doco on how to use the tc command. Well possibly one line - something along the lines of "see the usage message". His followers, Patrick included, have continued with that fine tradition. As far as I can tell they have never written a single line of user documentation. Thus the man entry for tc on Debian Lenny was written 8 years ago, by someone who trolled the kernel code to figure out how it worked. Recent additions by Jared and Patrick, such as mirred and redirect don't appear in any "official" documentation. The only information we get is quick HOWTO's posted to mailing lists.

If you want to really use this stuff at all you have to troll with google looking for either these snippets, or more commonly HOWTO's posted by others who have stumbled across the solution. Sadly the HOWTO's are often misleading, as you would expect from something developed by finding something close to what they wanted then fiddling to make it work for their particular application. They don't have much of an idea as to what is happening underneath, so their explanations as to why it works tend toward useless. If you really want to use this stuff to its full potential then you only have one choice: read the kernel source.

This may sound like just someone bitching, but if nftables gets in history will almost certainly repeat itself. Alexy decided that doing traffic control on ingress didn't make sense. Nonetheless, people wanted to do it, and eventually the IMQ module made it possible. IMQ had fairly good documentation. But the netfilter guys didn't like the way IMQ did things, so it never made it into the kernel. However the persistent popularity of IMQ eventually pushed them into providing a way to do incoming traffic control within the existing framework. Only, they never did bother documenting it, so figuring out how to use it takes a fair amount of effort. Needless to say IMQ lives on.

And Patrick introduced HSFC, a replacement for CBQ and HTB. Technically, HSFC is better than either - it is a nice qdisc. But naturally documentation is sparse, scattered across the internet, and mostly not written by Patrick.

In a nutshell, I'd take iptables with documentation over nftables without doco any day, regardless of how much better nftables is technically.

At a higher level, Linux is in dire need of a a change to Dave Millers patch acceptance policy. It should go something like this: if you make a kernel change that shows up at use level (eg by changes to the tc command), then the patch will only be accepted if there is a patch for the man page, and preferable a patch to an "official" tutorial somewhere giving examples of typical usage.