Hi. I've finished the kernel patch to fetch byte/packet conntrack counters. As discussed earlier, I added two modes: - fetch original or reply - fetch sum of original+reply direction (i.e. nft_ct adds original+reply before storing result into register). How should that look like on the userspace side? I see two solutions to handle this. Option one is to add a new pseudo-direction, e.g. "both": nft ... ct packets both gt 42 nft ... ct packets original gt 42 Second option -- which I'd prefer -- is to allow omitting the direction. This seems possible w.o. adding parser problems by switching direction and key, so we'd have: nft ... ct packets gt 42 nft ... ct reply packets gt 42 nft ... ct original packets gt 42 Because parser would just add ct_key_counters : BYTES | PACKETS; ct_expr: CT ct_key_counters | CT STRING ct_key_counters which doesn't introduce ambiguity (original and reply aren't scanner tokens, unlike ct_keys) If we follow this route, i'd also swap the direction and key argument for the existing saddr/daddr/etc keys, i.e. instead of ... 'ct saddr original 1.2.3.4' we'd have ... ct original saddr 1.2.3.4 ... This would make packets/bytes work *both* like ct_keys with and without direction: ct mark gt 42 ---> fetch mark ct original mark gt 42 -> parser error, mark can only be used w/o dir ct saddr 1.2.3.4 -> parser error, saddr needs direction ct original saddr 1.2.3.4 -> fetch ct saddr in original dir ct packets gt 42 -> fetch sum of packet counter for original and reply ct original packets gt 42 -> fetch packet counter for original What do others think? Swapping key and direction breaks backwards compatibility but this was added only recently so I think it shouldn't be a problem. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
