David Miller <davem@xxxxxxxxxxxxx> wrote: > From: Phil Sutter <phil@xxxxxx> > Date: Mon, 19 Feb 2018 18:14:11 +0100 > > > OK, so reading between the lines you're saying that nftables project > > has failed to provide an adequate successor to iptables? > > Whilst it is great that the atomic table update problem was solved, I > think the emphasis on flexibility often at the expense of performance > was a bad move. Thats not true, IMO. One idea previosuly discussed was to add a 'freeze' option to our nftables syntax. Essentially what would happen is that further updates to the table become impossible, with exception of named sets (which can be changed independently similar to ebpf maps is suppose). As further updates to the table are then no longer allowed this would then make it possible to e.g. jit all rules into a single program. The table could still be removed (and recreated) of course so its not impossible to make changes, but no longer at the rule level. > Netfilter's chronic performance differential is why a lot of mindshare > was lost to userspace networking technologies. I think this is a unfair statement and also not true. If you refer to the linear-ruleset-evaluation of iptables, this is what ipset was added for. Yes, its a band aid. But again, that problem come from the UAPI format/limitations of only having one source or destination address per rule, a limitation not present in nftables. Other reason why iptables is a bit more costly than needed (although it IS rather fast given, no spinlocks in main eval loop) are the rule counter updates which were built into the design all those years ago. Again, a problem solved in nftables by making the counters optional. If you want to speedup forward path with XDP -- fine. But AFAIU its still possible with XDP to have packets being sent to full stack, right? If so, it would be possible to even combine nftables with XDP, f.e. by allowing an ebpf program running on host CPU to query netfilter conntrack. No Entry -> push to normal path Entry -> check 'fastpath' flag (which would be in nf_conn struct). Not set -> also normal path. Otherwise continue XDP, stack bypass. nftables would have a rule similar to this: nft add rule inet forward ct state established ct label set fastpath to switch such conntrack to xdp mode. This decision can then be combined with nftables infra, for example 'fatpath for tcp flows that saw more than 1mbit of data in either direction' or the like. Yes, this needs ebpf support for conntrack and NAT transformations, and it does beg question how to handle the details, e.g. conntrack timeouts. Don't see any unsolveable issues with this though. Also has similarities with the 'flow offload' proposal, i.e. we could perhaps even reuse what we already have to add provide flow offload in software using epbf/XDP as offload backend. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
