Date: Sun, 19 Oct 2008 21:22:20 +0800 From: Eugene Grosbein <eugen@kuzbass.ru> To: Hartmut Brandt <hartmut.brandt@dlr.de> Cc: net@freebsd.org Subject: Re: SNMP High Capacity Counters Message-ID: <20081019132220.GA97807@svzserv.kemerovo.su> In-Reply-To: <48FB1739.8020608@dlr.de> References: <20081018092405.GA91929@svzserv.kemerovo.su> <48FA1A7C.5060801@dlr.de> <20081018184140.GA71679@svzserv.kemerovo.su> <48FB1739.8020608@dlr.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 19, 2008 at 01:17:13PM +0200, Hartmut Brandt wrote: > The problem is not the CPU horsepower. The problem is that you update > these counters on each incoming packet. No problem for desktops, but if > you want to route several 100kps this may hurt. I have no idea, how IPFW > does it. Perhaps it just declares the variables as 64-bit and if the > value is wrong because of a race condition, then it is just wrong. With > SNMP I would not like to have wrong counters - people use these counters > for accounting purposes. IPFW defines its counters as u_int64_t and uses mtx_lock/mtx_unlock while updating. Basically, this means lots of locking for every packet for IPFW-enables system. I do not say we need 64 bit stats in kernel by default. Just optionally, for those that have no problem with pps but likes to have 64 bit ifHC*'s. Eugene Grosbein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081019132220.GA97807>