Hi,I've been working for a while to recover nf_tables kernel patches andto implement a compatibility layer so it can be used with existingx_tables target/match extensions. These are the main reasons thatmotivated me to follow this approach:1) nf_tables already provides a netlink interface, which has been a   longstanding demand from users.2) Provide a fast path to merge this into mainstream. We'll have both   iptables and nftables interfaces during some time in the Linux kernel,   then remove iptables infrastructure at some point. iptables scripts   would not break as we'll have the iptables emulation over nftables.3) Regarding the compatibility layer: To provide a working command   line utility with the same syntax of iptables. The idea is that users   don't notice that they are working with the nf_tables kernel   infrastructure. We did that during the transition from ipchains to   iptables.4) Several extensions for x_tables still need to be ported to   nf_tables. With the compatibility layer, we can use non-native   x_tables extensions with nf_tables until it fully provides a   replacement for all existing features.5) The compatibility layer provides a way to hook existing x_tables   matches/targets with nftables. So we can use all existing features   from nftables until we provide native nftables expressions /   user-space code that replace them.The compatibility layer has limitations to emulate struct ipt_entry,hookmask, protocol and inversion passed to xt->checkentry(). But thiscan be mostly workaround by relaxing some of the checking inkernel-space that prevent users from doing stupid things (like tryingto use the TCPMSS target for non-TCP traffic / non-syn packets). In mylist, the affected targets are ECN, CLUSTERIP, TCPMSS, REJECT and CT.I have some proposals on how to workaround those.You can access the preliminary iptables over nftables code from:http://1984.lsi.us.es/git/iptables-nftables/The name of the utilities are xtables, xtables-save andxtables-restore.There are several missing features in that iptables over nftablescode: -Z, -R, -E, rule insertion at position and -f are not yetworking. IPv6 support is also still missing.It requires this user-space library:http://1984.lsi.us.es/git/libnftables/And the following Linux kernel code with several experimental patchesof mine:http://1984.lsi.us.es/git/nf-next/log/?h=nf_tables-experimentsI see several things that need to be improved in the nftables kernelside:1) Improve rule addition and deletion timing, currently it is notvery good compared to iptables. To improve deletions I think wehave to modify the current locking approach based on RCU. To improveadditions, we have to improve the unique handle allocation (probablyusing a 64-bits handle number so we forget about wrap-arounds and wejust incrementally assign new handles).2) No built-in nat and route tables. Better allow from user-spaceconfigure one table with the nat / route property. If we providedocumentation on how to use them appropriately, I would not worry toomuch if the user uses wrongly.3) Add operation to obtain chain counters, following the same approachof iptables (iterate over the entire rule-set and accumulate packetsand bytes, like in get_counters()).4) Add native support for TRACE, it seems to be missing in nf_tables.5) Changes to allow to add rules at positions and replace them, sinceiptables allows this.6) To speed up packet matching, we can compile nftables expressions tosome internal bytecode (that could be even compiled to native assemblyinstructions like Eric Dumazet did for BPF).Several of these things can be improved while we already have this inmainline.One final thing: nftables does not support atomic table commit. Thepoint here is if we really need this for the emulation utility or wecan live without that. Implementing atomic table replacement innftables is not trivial. I have hard time to find this commit tablefeature useful.That's all by now. By resolving most of these things and having thecompatibility layer ready, we should get nftables into mainstreamanytime soon IMO.Comments welcome.Regards.--To unsubscribe from this list: send the line "unsubscribe netfilter-devel" inthe body of a message to majordomo@xxxxxxxxxxxxxxxMore majordomo info athttp://vger.kernel.org/majordomo-info.html