All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>,
	Rick Jones <rick.jones2@hp.com>, Tom Parkin <tparkin@katalix.com>,
	netdev@vger.kernel.org, David.Laight@ACULAB.COM,
	James Chapman <jchapman@katalix.com>
Subject: Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
Date: Wed, 27 Jun 2012 14:40:16 -0700	[thread overview]
Message-ID: <4FEB7DC0.9090404@candelatech.com> (raw)
In-Reply-To: <1340832771.26242.160.camel@edumazet-glaptop>

On 06/27/2012 02:32 PM, Eric Dumazet wrote:
> On Wed, 2012-06-27 at 23:20 +0200, Eric Dumazet wrote:
>> On Wed, 2012-06-27 at 13:58 -0700, Ben Greear wrote:
>>
>>> It's worse than that:  Even on 64-bit kernels, counters that are returned by
>>> netlink and /proc/net/dev as 64-bit may still wrap themselves at 32-bit
>>> intervals.
>>
>> Really ?
>>
>> Thats incredible you dont send a bug report then.
>
> A bug report to the application author, not the kernel.

Yeah, application author was me.

> /proc/net/dev is an ASCII file, and nothing gives the width of a field.
>
> Therefore, an application should cope with all cases (counter being a
> 32bit or 64bit integer), wrapping included.
>
> Note that this has little to do with the application or kernel being
> 32/64 bit code.

Notice that the netlink stats are claiming 64-bit and they are not
(always) 64-bit.

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.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

  reply	other threads:[~2012-06-27 21:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-27 12:00 [PATCH v2] l2tp: use per-cpu variables for u64_stats updates Tom Parkin
2012-06-27 19:03 ` Eric Dumazet
2012-06-27 20:21   ` Rick Jones
2012-06-27 20:39     ` Eric Dumazet
2012-06-27 20:50       ` Stephen Hemminger
2012-06-27 20:58         ` Ben Greear
2012-06-27 21:20           ` Eric Dumazet
2012-06-27 21:31             ` Ben Greear
2012-06-27 21:35               ` Eric Dumazet
2012-06-27 23:01                 ` Rick Jones
2012-06-27 23:09                   ` David Miller
2012-06-27 23:39                     ` Rick Jones
2012-06-28  5:00                   ` Eric Dumazet
2012-06-28  8:24                     ` Tom Parkin
2012-06-28  8:46                     ` David Laight
2012-06-28 18:17                       ` Ben Hutchings
2012-06-27 21:32             ` Eric Dumazet
2012-06-27 21:40               ` Ben Greear [this message]
2012-06-27 21:50                 ` Eric Dumazet
2012-06-27 21:00       ` Rick Jones
2012-06-27 22:21       ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FEB7DC0.9090404@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=eric.dumazet@gmail.com \
    --cc=jchapman@katalix.com \
    --cc=netdev@vger.kernel.org \
    --cc=rick.jones2@hp.com \
    --cc=shemminger@vyatta.com \
    --cc=tparkin@katalix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.