[CRIU] [PATCHv2 1/2] net: add nftables c/r

[Kirill Gorkunov]

On Wed, Nov 13, 2019 at 08:29:15PM -0800, Andrei Vagin (C) wrote:
> On Wed, Nov 13, 2019 at 02:14:06PM +0000, Alexander Mikhalitsyn wrote:
> > On Wed, 13 Nov 2019 00:45:20 -0800
> > Andrei Vagin <avagin at gmail.com> wrote:
> > 
> > > On Tue, Nov 12, 2019 at 07:06:42PM +0300, Alexander Mikhalitsyn wrote:
> > > > From: Pavel Tikhomirov <ptikhomirov at virtuozzo.com>
> > > > 
> > > > After Centos-8 nft used instead of iptables. But we had never supported nft rules in
> > > > CRIU, and after c/r all rules are flushed.
> > > > 
> > > > Path to nft tool can be changed via CR_NFTABLES environment variable
> > > > similar to CR_IPTABLES.
> > > 
> > > 
> > > Can we use libnftnl? This should be faster, because we will not need to
> > > fork a new process and exec a binary.
> > > 
> 
> > Good point, but we have some problems with that. Currently, when we do
> > "nft list ruleset" it output have special format (that corresponds to
> > formal grammar defined by (nftables/src/parser_bison.y)). It's not
> > format that supported by libnftnl. Currently libnftnl supports only
> > dumping ruleset in "command format" as a sequence of nft commands that
> > describes current ruleset. But if we try to use this format on
> > Checkpoint in CRIU, then we have a problems on Restore - we need to
> > execute a lot (maybe) "nft ..." commands. In performance terms it may
> > be even worse then as we doing now. Of course, we can grab this parser
> > from nftables to CRIU, but it's a lot of code and then we need
> > additional compile-time deps - Bison for example. I don't know what to
> > choose... :)
> 
> Maybe we can use this way:
> 
> on dump:
>   * create a netlink socket
>   * send a request to list all rules
>   * save raw netlink messages in an image file.
> 
> on restore:
>   * create a netlink socket
>   * send netlink messages from the image file into the socket.
> 
> "ip addr save" and "ip addr restore" work this way.
> https://github.com/shemminger/iproute2/blob/master/ip/ipaddress.c#L1552
> https://github.com/shemminger/iproute2/blob/master/ip/ipaddress.c#L1618

Which implies to move in part of netlink protocol into criu.
Personally I don't mind but to me this looks a bit complex.
I would rather stick with not that fast but more reliable
usage of exec'ing CR_NFTABLES and the we could try to
implement builtin (netlink based) data fetch from
the kernel.