Optimize the checkpoint/restore TCP connection performance by using netlink API

[time-river]

The PR #1539 ([GSoC] Add nftables based network locking/unlocking) isn't good, although it has the better performance compared with iptables cmd. The tcp connection can be locked/unlocked by nftables netlink API. Compared with iptables cmd, it has 90%+ performance improvement.

The core idea is:

• use netlink API to create nftables rules
  • only for rules (two for IPv4, two for IPv6) are created
• use nftables set to store src:port-dst:port elements instead of filter rules

[rst0git]

@time-river Thank you for your feedback. The main goal of the pull request you pointed out was not performance optimization but to avoid dependency on the iptables-restore external binary. We have encountered several problems related to this (https://github.com/checkpoint-restore/criu/issues/561, https://github.com/checkpoint-restore/criu/issues/551, https://github.com/checkpoint-restore/criu/issues/514, https://github.com/checkpoint-restore/criu/issues/485, https://github.com/checkpoint-restore/criu/issues/469).

This pull request also adds the --network-lock [mode] option that allows CRIU to be extended in the future with support for different TCP connection lock/unlock mechanism.

The tcp connection can be locked/unlocked by nftables netlink API.

Pull requests are always welcome! ;)

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[rahulk789]

Hey there :wave: Will be working on this. Also reading on 1816. If anyone would like to add onto the earlier comments for clarification/suggestions, that would be great. Thank you!!

[rahulk789]

Updates: Will be modifying the code from examples of libnftnl library. The examples nft-chain-add.c , nft-rule-add.c and nft-table-add.c seem to fit our usecase. Fixing this issue should remove our dependency of nft tables binary and instead have libnftnl and libmnl library dependencies.