All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: netfilter-devel@vger.kernel.org
Subject: [nft] syntax for retrieving ct byte/packet counters
Date: Thu, 7 Jan 2016 14:43:51 +0100	[thread overview]
Message-ID: <20160107134351.GD23789@breakpoint.cc> (raw)

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.

             reply	other threads:[~2016-01-07 13:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-07 13:43 Florian Westphal [this message]
2016-01-07 17:53 ` [nft] syntax for retrieving ct byte/packet counters Pablo Neira Ayuso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160107134351.GD23789@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.