On Tue, Jul 26, 2016 at 04:25:17PM +0200, Michal Privoznik wrote: > Dear list, > > I've came across nftables [1]. They look very promising, more than old > netfilter. It offers new features [2], from which I'd pick: > > - better performance under high traffic workloads > - atomic filter/chain replacements > - transactions > > I haven't investigated how much work will be required on our side if we > try to implement the switch (well, for starters, we can have two > subsystems living next to each other). I want to check what do you guys > think before actually digging into the code. > > The nftables was merged into 3.13 Linux kernel and thus should be > available on all major distros. Well, since we will have both subsystems > available, we should be good to go. So from the kernel side netfilter & nftables are completely separate subsystems, but you don't really want to use both at the same time on the same host. In theory there's compat code to translate [eb,ip,ip6]tables commands to nft commands, but IIUC that is incomplete. IOW, there is likely to need to be a "flag day" for each distro when they switch over to use nftables, and all apps dealing with firewalls will need to be capable of switching at once. So a nftables backend is not immediately useful for libvirt, but at the same time, developing one is probably a pre-requisite for any distro using libvirt to be able to switch to nftables. Firewalld does not currently have any nftables support in its git master either. If it does, then there's an open question as to whether libvirt should actually continue to use firewalld or not. We use firewalld today because netfilter has a fixed set of base chains, and we need to preserve libvirt rules in those chains when firewalld makes changes. In nftables, there's no fixed base chains - apps just define the base chains they want. So in theory libvirt can define its own table and chains without needing to worry about firewalld, as its chains will be completely separate. Looking at the syntax of 'nft' its quite different from iptables, so libvirt support will require a completely new backend for nwfilter, and adaptation to the virtual network firewall code. So that's a pretty major amount of work and major testing impact. > BTW: it's a bit shame that this nifty project hasn't received much more > advertising. Looks cool so far. I'd say the main blocker is the fact that you have to effectively choose netfilter or nftables, as the compat layer is not good enough to be used in the real world. This pretty much prevents distros from using it by default until all apps are converted. IOW, the same kind of reason why python2 still exists & is heavily, despite python3 being around for years, except worse as at least with python both run in parallel Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list