<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 13, 2019, 11:04 PM Kirill Gorkunov <<a href="mailto:gorcunov@virtuozzo.com" rel="noreferrer noreferrer" target="_blank">gorcunov@virtuozzo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Nov 13, 2019 at 08:29:15PM -0800, Andrei Vagin (C) wrote:<br>
> On Wed, Nov 13, 2019 at 02:14:06PM +0000, Alexander Mikhalitsyn wrote:<br>
> > On Wed, 13 Nov 2019 00:45:20 -0800<br>
> > Andrei Vagin <<a href="mailto:avagin@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">avagin@gmail.com</a>> wrote:<br>
> > <br>
> > > On Tue, Nov 12, 2019 at 07:06:42PM +0300, Alexander Mikhalitsyn wrote:<br>
> > > > From: Pavel Tikhomirov <<a href="mailto:ptikhomirov@virtuozzo.com" rel="noreferrer noreferrer noreferrer" target="_blank">ptikhomirov@virtuozzo.com</a>><br>
> > > > <br>
> > > > After Centos-8 nft used instead of iptables. But we had never supported nft rules in<br>
> > > > CRIU, and after c/r all rules are flushed.<br>
> > > > <br>
> > > > Path to nft tool can be changed via CR_NFTABLES environment variable<br>
> > > > similar to CR_IPTABLES.<br>
> > > <br>
> > > <br>
> > > Can we use libnftnl? This should be faster, because we will not need to<br>
> > > fork a new process and exec a binary.<br>
> > > <br>
> <br>
> > Good point, but we have some problems with that. Currently, when we do<br>
> > "nft list ruleset" it output have special format (that corresponds to<br>
> > formal grammar defined by (nftables/src/parser_bison.y)). It's not<br>
> > format that supported by libnftnl. Currently libnftnl supports only<br>
> > dumping ruleset in "command format" as a sequence of nft commands that<br>
> > describes current ruleset. But if we try to use this format on<br>
> > Checkpoint in CRIU, then we have a problems on Restore - we need to<br>
> > execute a lot (maybe) "nft ..." commands. In performance terms it may<br>
> > be even worse then as we doing now. Of course, we can grab this parser<br>
> > from nftables to CRIU, but it's a lot of code and then we need<br>
> > additional compile-time deps - Bison for example. I don't know what to<br>
> > choose... :)<br>
> <br>
> Maybe we can use this way:<br>
> <br>
> on dump:<br>
> * create a netlink socket<br>
> * send a request to list all rules<br>
> * save raw netlink messages in an image file.<br>
> <br>
> on restore:<br>
> * create a netlink socket<br>
> * send netlink messages from the image file into the socket.<br>
> <br>
> "ip addr save" and "ip addr restore" work this way.<br>
> <a href="https://github.com/shemminger/iproute2/blob/master/ip/ipaddress.c#L1552" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://github.com/shemminger/iproute2/blob/master/ip/ipaddress.c#L1552</a><br>
> <a href="https://github.com/shemminger/iproute2/blob/master/ip/ipaddress.c#L1618" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://github.com/shemminger/iproute2/blob/master/ip/ipaddress.c#L1618</a><br>
<br>
Which implies to move in part of netlink protocol into criu.<br>
Personally I don't mind but to me this looks a bit complex.<br>
I would rather stick with not that fast but more reliable<br>
usage of exec'ing CR_NFTABLES and the we could try to<br>
implement builtin (netlink based) data fetch from<br>
the kernel.<br></blockquote></div></div><div dir="auto"><br><span style="font-family:sans-serif">I believe we already have all required parts of netlink in the criu code base. And our experience with the iptable tool showed that tools are not always reliable. I think it's worth to try to implement this and see how it will looks like. I think it should not take more than an hour or two.</span><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>