On Thu, Jan 07, 2016 at 02:43:51PM +0100, Florian Westphal wrote: > 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. If that is the only problem, we didn't make any release so far, so no objection from my side. -- 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
