Re: Accounting objects support in nft

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Mon, Jan 12, 2015 at 12:37:11PM +0000, Patrick McHardy wrote:
> 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.

Agreed.