[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1340833849.26242.186.camel@edumazet-glaptop>
Date: Wed, 27 Jun 2012 23:50:49 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Ben Greear <greearb@...delatech.com>
Cc: Stephen Hemminger <shemminger@...tta.com>,
Rick Jones <rick.jones2@...com>,
Tom Parkin <tparkin@...alix.com>, netdev@...r.kernel.org,
David.Laight@...LAB.COM, James Chapman <jchapman@...alix.com>
Subject: Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
On Wed, 2012-06-27 at 14:40 -0700, Ben Greear wrote:
> Notice that the netlink stats are claiming 64-bit and they are not
> (always) 64-bit.
There is no such claim.
netlink provides a 64bit generic binary holder, even for legacy drivers
still using 'unsigned long' stats, so obviously 32bit values on 32bit
kernels.
> That is a nice binary API that is still wrapping before its time
> in many cases. There may be good performance reasons for keeping
> some counters at 32-bit, but it plays merry hell with anyone wanting
> to optimize an application to poll less often for stats that are
> supposedly 64-bit.
We dont want hundred of patches to bring 64bit stats on legacy drivers.
Nobody cares, because its way too late to try to 'fix' this.
If you want your application running on linux-2.6.x, or linux-3.0, you
are forced to correctly detect each counter being 32 or 64, not because
netlink API is 64bit, but because a driver provides a 32 or 64 bit
value.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists