From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: Accounting objects support in nft Date: Mon, 12 Jan 2015 12:37:11 +0000 Message-ID: <20150112123711.GL3491@acer.localdomain> References: <20150112123516.GA4546@salvia> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Arturo Borrero Gonzalez , ana@soleta.eu, Netfilter Development Mailing list To: Pablo Neira Ayuso Return-path: Received: from stinky.trash.net ([213.144.137.162]:34918 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753044AbbALMhQ (ORCPT ); Mon, 12 Jan 2015 07:37:16 -0500 Content-Disposition: inline In-Reply-To: <20150112123516.GA4546@salvia> Sender: netfilter-devel-owner@vger.kernel.org List-ID: 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, 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.