Re: Accounting objects support in nft

[Patrick McHardy <kaber@trash.net>]

On 12.01, Pablo Neira Ayuso wrote:
> On Mon, Jan 12, 2015 at 12:48:35PM +0100, Arturo Borrero Gonzalez wrote:
> > On 12 January 2015 at 11:55,  <ana@soleta.eu> wrote:
> > >
> > > table ip filter {
> > >         acct http-traffic { pkts 779 bytes 99495}
> > >         acct https-traffic { pkts 189 bytes 37824}
> > >
> > >         chain output {
> > >              type filter hook output priority 0;
> > >              tcp dport http acct http-traffic
> > >              tcp dport https acct https-traffic
> > >         }
> > > }
> > >
> >
> > Interesting, Ana!
> >
> > I understand that acct objects are bounded to a table/family.
> > Why not make them globals? So we could increment same counters from
> > different families/tables.
> 
> Indeed. The existing binding between acct and tables is superfluous.
> With sets, we need that to check for loops in verdict maps.
> 
> So counters can become also top-level identifier as it happens with
> tables, ie.
> 
> counters {
>         http-traffic { pkts 779 bytes 99495}
>         acct https-traffic { pkts 189 bytes 37824}
> }
> 
> table ip filter {
>         chain output {
>              type filter hook output priority 0;
>              tcp dport http counter http-traffic
>              tcp dport https counter https-traffic
>         }
> }
> 
> Patrick, any comment on that?

I'm unsure, we don't have any global objects so far, this might open
another can of flushing/ordering etc problems. If it works without
problems, I can see both variants being useful. Given that we only
need a list to store them we might be able to support both by minor
adjustments to the lookup function.

If we do actually want to support both, I'd suggest to start using
just table scope and expand it later.