"Atomic" snapshot of counters

"Atomic" snapshot of counters

[Thomas Heinz]

Hi

Netfilter produces an atomic snapshot of counters, i.e. the table is
locked during the gathering of the counter values. Of course no packet
is matched while this lock is active.

How important is it to have such an atomic snapshot? The reason why
I'm asking this question is because Michael and I intend to implement
the nf-hipac rule listing (and especially the counter gathering)
mechanism in a way that it does not interrupt the packet matching.
This obviously implies that the counter snapshot cannot be atomic and
is therefore inaccurate in some way.
For example consider a chain A containing two rules x and y.
Now we fix the counter value of x and just before fixing the counter
value of y a packet matching x and y is processed. This packet would
only appear in the counter for y but not in the one for x.

Does this really matter or is it in fact unimportant because the error
is very marginal compared to the absolute counter values (not to forget
the performance gain).

Thanks for your rating.


Regards,

Thomas

Re: "Atomic" snapshot of counters

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

On Fri, Jan 24, 2003 at 01:35:00AM +0100, Thomas Heinz wrote:
> Hi
> 
> Netfilter produces an atomic snapshot of counters, i.e. the table is
> locked during the gathering of the counter values. Of course no packet
> is matched while this lock is active.

yes. This was thought to be one of 'the' advantages of iptables over
ipchains.

> How important is it to have such an atomic snapshot? 

From my current point of view: not that important.  My pkt_tables plans
[which are meant to eventually replace ip_tables] also don't have this
atomicity anymore.

> Regards,
> Thomas

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: "Atomic" snapshot of counters

[Thomas Heinz]

Hi Harald

Thanks for your comment.

You wrote:
>>How important is it to have such an atomic snapshot? 
> 
> From my current point of view: not that important.  My pkt_tables plans
> [which are meant to eventually replace ip_tables] also don't have this
> atomicity anymore.

Well, Michael and I had some discussion about the counter issue.
Finally, we decided to implement atomic counters but without freezing
the packet matching. We're using two counter pairs per rule. One is
a kind of overflow counter which is used after a snapshot has been
requested, i.e. all packets being machted after the snapshot has been
requested are added to the second counter. After the rules are delivered
to user space the counter pairs are "fixed", i.e. the second counter
is added to the first one and set to 0 afterwards.

This is simple. The more complicated part is based on the fact that an
insert or delete operation which appears sort of "atomic" to the user
might be expanded to several hipac rules on the kernel side.
But we also found a solution for this issue that does not require
stopping the packet matching.

BTW another topic: I've just read that you don't consider the
netfilter-devel mailing list the right place for gtk-iptables
announcements. In the past, Michael and I also posted announcements
about nf-hipac to netfilter-devel (and netfilter user mailing list) :-)
We did so because we thought (and still believe :) that nf-hipac
might be interesting for netfilter developers too (especially the
next version which will include generic support for iptables
targets/matches and user-defined chains).

Just drop us a line if you think that upcoming nf-hipac announcements
should not be posted to netfilter-devel. This is not a problem or
whatsoever ;-)


Regards,

Thomas