All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [nft] syntax for retrieving ct byte/packet counters
Date: Thu, 7 Jan 2016 18:53:21 +0100	[thread overview]
Message-ID: <20160107175321.GA1481@salvia> (raw)
In-Reply-To: <20160107134351.GD23789@breakpoint.cc>

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.

      reply	other threads:[~2016-01-07 17:53 UTC|newest]

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

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=20160107175321.GA1481@salvia \
    --to=pablo@netfilter.org \
    --cc=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.