Re: connbytes & 64bit counters

[Patrick McHardy <kaber@trash.net>]

Krzysztof Oledzki wrote:
> Errr, incomplete patch, sorry... This one should work.
> 
> [NETFILTER]: Reimplementation of 64bit counters for bytes/packets
> accounting


I thought about this today, but came to no conclusion. We have ct_extend
now, allowing to allocate the counters dynamically for new conntracks,
and the only reasonable thing IMO (considering distributors that waste
16 bytes per conntrack for a feature pratically *nobody* uses, with your
patch that actually fixes a regression 32 byte) would be to make
accounting optional and triggered by a target in the raw table. Its so
far used by default and the counters are visible through /proc and
ctnetlink though. So this would break compatibility. OTOH I think its
totally ridiculous to waste this much memory for something pratically
nobody uses. So my current opinion is between just breaking
compatibility (with some grace period perhaps) and trying to behave
half-way compatible when ctnetlink is loaded. I don't think the second
option will work though. And frankly, the current code it totally
broken, it will send a COUNTER_OVERFLOW event *for each packet* when
the counters exceed 2^31. So its really questionable if anyone actually
uses this, without further patches.

Opinions are welcome.