From owner-freebsd-net@FreeBSD.ORG Sat Nov 8 01:13:54 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 028B516A4CE for ; Sat, 8 Nov 2003 01:13:53 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8250843F75 for ; Sat, 8 Nov 2003 01:13:52 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])hA89DmU01446; Sat, 8 Nov 2003 10:13:48 +0100 (MET) Date: Sat, 8 Nov 2003 10:13:48 +0100 (CET) From: Harti Brandt To: Alex Hoff In-Reply-To: Message-ID: <20031108100926.M78050@beagle.fokus.fraunhofer.de> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "'freebsd-net@freebsd.org'" Subject: Re: 64 bit packet counters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2003 09:13:54 -0000 On Fri, 7 Nov 2003, Alex Hoff wrote: AH>Hi, AH> AH>We are attempting to implement the IF-MIB, which requires the use of 64 bit AH>packet counters and the differentiation between multicast and broadcast AH>pkts. Since changing the if_data (by adding new counters and changing the AH>existing to u_int64) is a bad idea, does anyone have any good ideas on how AH>to do this? I was thinking of tacking on a new struct (lets call it AH>ifx_data) on at the end of the current if_net struct with the appropriate AH>counters (i/opacket, i/obyte, i/obcast, i/omcast). Apart from having to do a AH>little double counting is there any obvious pitfals with this approach? Does AH>anyone have an better ideas? Is there currently any plans to update the AH>network stack to handle this properly? You may lookup the discussions in the mailing lists. As far as I remember the problem with 64 bit counting was that this needs locks because not on all architectures you have atomic 64bit add operations. A simple method that does not involve kernel changes (and that I plan to implement in my snmp daemon) is to periodically monitor the counters (depending on the interface speed) and detect wraps in the daemon. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org