Serguei Bezverkhi (sbezverk) <sbezverk@xxxxxxxxx> wrote: > Ok, I figured out the map issue, it was a length of the key in bits, damn copy/paste ( > > Appreciate if somebody could comment about the following: > > sudo nft --debug=netlink insert rule ip6 kube-nfproxy-v6 k8s-nat-services ip6 nexthdr . ip6 daddr . th dport vmap @cluster-ip-set > ip6 kube-nfproxy-v6 k8s-nat-services > [ payload load 1b @ network header + 6 => reg 1 ] > [ payload load 16b @ network header + 24 => reg 9 ]. < -- Is it loading reg 9 4-bytes, reg 10 4 bytes etc until reg 12? Or because the data 16 bytes long it has to skip 3 more register? > [ payload load 2b @ transport header + 2 => reg 13 ] The 'registers' are adjacent in memory, so loading 16 bytes to reg9 will also store data to 10, 11 and 12. In case there are not enough next registers kernel will reject the transaction. > [ lookup reg 1 set cluster-ip-set dreg 0 ] > > I am just trying to figure out how to calculate next register to use. If there is algorithm for both ipv4 and ipv6 that would be awesome to know. See netlink_gen_concat() in src/netlink_linearize.c in nftables. Its basically enough to take the start register and then add the length, rounded up to 4 (register is always 4 byte). So for the above you need 1 + 1 * 4 + 1, i.e. 6 registers, then pass the first/start register to the lookup expression. The lookup expression takes the number of 'next registers' it needs to look at from the set key length.
