From owner-freebsd-net@FreeBSD.ORG Sun Oct 19 13:22:28 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 647BD106568F for ; Sun, 19 Oct 2008 13:22:28 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id B35638FC1C for ; Sun, 19 Oct 2008 13:22:27 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m9JDMLk1099474; Sun, 19 Oct 2008 21:22:21 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m9JDMKuL099473; Sun, 19 Oct 2008 21:22:20 +0800 (KRAST) (envelope-from eugen) Date: Sun, 19 Oct 2008 21:22:20 +0800 From: Eugene Grosbein To: Hartmut Brandt Message-ID: <20081019132220.GA97807@svzserv.kemerovo.su> References: <20081018092405.GA91929@svzserv.kemerovo.su> <48FA1A7C.5060801@dlr.de> <20081018184140.GA71679@svzserv.kemerovo.su> <48FB1739.8020608@dlr.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48FB1739.8020608@dlr.de> User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: SNMP High Capacity Counters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2008 13:22:28 -0000 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