Received: with ECARTIS (v1.0.0; list netdev); Sat, 05 Jul 2003 13:53:19 -0700 (PDT) Received: from mta2.srv.hcvlny.cv.net (mta2.srv.hcvlny.cv.net [167.206.5.5]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h65KrE2x031532 for ; Sat, 5 Jul 2003 13:53:15 -0700 Received: from asv19.srv.hcvlny.cv.net (asv19.srv.hcvlny.cv.net [167.206.5.173]) by mta2.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HHK00K63JZ9MF@mta2.srv.hcvlny.cv.net> for netdev@oss.sgi.com; Sat, 05 Jul 2003 16:37:57 -0400 (EDT) Received: from jeff.home (ool-44c2049f.dyn.optonline.net [68.194.4.159]) by asv19.srv.hcvlny.cv.net (8.12.9/8.12.9) with ESMTP id h65KaujJ009847; Sat, 05 Jul 2003 16:36:57 -0400 (EDT) Date: Sat, 05 Jul 2003 16:37:43 -0400 From: Jeff Sipek Subject: Re: [PATCH - RFC] [1/5] 64-bit network statistics - generic net In-reply-to: To: Bernd Eckenfels , linux-kernel@vger.kernel.org Cc: Andrew Morton , Dave Jones , Linus Torvalds , netdev@oss.sgi.com, Jeff Garzik Message-id: <200307051637.52252.jeffpc@optonline.net> MIME-version: 1.0 Content-type: Text/Plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline Content-description: clearsigned data User-Agent: KMail/1.5.2 References: X-archive-position: 3776 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeffpc@optonline.net Precedence: bulk X-list: netdev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 05 July 2003 15:58, Bernd Eckenfels wrote: > a reader like ifconfig can easyly work around this with multiple tries, but > incremeting those variables wont work that easy, and therefore needs a > lock, which will be a major pita. > > 64bit counters should be a result of lockless per-cpu network counters > (32bit) with some kind of async merging. This is going to make the structure huge - not only you have the 32-bit variables for every CPU, but you have one global set of 64-bit variables (possibly you will need a lock for the 64-bit vars.) Also another thing to consider is portability across architectures - we don't need all this code on 64-bit arches. On the other hand, per-cpu stats may possibly make up for the extra code - no cache bouncing, etc. > Or we wait till 64bit hardware is more common :) Hehe, the thing is, that when 64bits beecome more common you will have this huge number of unused x86 computers that people will: - - throw out - - donate - - convert to all sorts of "embedded" systems which need stable OS (read: Linux) (these include routers) So, x86 is here to stay for some time. Jeff. - -- The Moon is Waxing Crescent (36% of Full) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/BzcbwFP0+seVj/4RAuMHAJ9sN0E4OgsPeM09D6hbgM3boECLDwCbBDTP 6u8SSobW0+Y0oWq3H4koHd0= =Z89A -----END PGP SIGNATURE-----