Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 12 Jul 2002 17:59:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 12 Jul 2002 17:59:20 -0400 Received: from grunt.ksu.ksu.edu ([129.130.12.17]:20426 "EHLO mailhub.cns.ksu.edu") by vger.kernel.org with ESMTP id ; Fri, 12 Jul 2002 17:59:19 -0400 Date: Fri, 12 Jul 2002 17:02:07 -0500 (CDT) From: Matt Stegman X-X-Sender: To: Stephen Hemminger cc: linux-kernel Subject: Re: 64 bit netdev stats counter In-Reply-To: <1026503694.26819.4.camel@dell_ss3.pdx.osdl.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1455 Lines: 45 On 12 Jul 2002, Stephen Hemminger wrote: > 64 bit values are not atomic so on x86 there will be glitches if this > ever wraps over on an SMP machine. One other engineer is already > adressing this for inode values like size; but this would introduce the > same problem for network stuff. One other solution I thought of would be to have an rx_bytes_wrap counter in the struct. struct net_device_stats { ... unsigned long rx_bytes; unsigned long rx_bytes_wrap; unsigned long tx_bytes; unsigned long tx_bytes_wrap; ... } ... and then, everywhere we add to rx_bytes (or tx_bytes): stats->rx_bytes += pkt_length; if (stats->rx_bytes <= pkt_length) stats->rx_bytes_wrap++; I suppose this might also be more backwards compatible - if other code I don't know about expects the rx_bytes to be a long, this would keep it so. Also, if gcc has real problems with doing 64-bit math on a 32-bit processor, this keeps everything in 32-bits. I could then make a local "unsigned long long" variable in the code that prints /proc/net/dev, and in ifconfig. unsigned long long rx_total_bytes = stats->rx_bytes * stats->rx_bytes_wrap; sprintf(buf, "RX bytes:%llu", stats->rx_total_bytes); -- -Matt Stegman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/