From: Stephen Hemminger <shemminger@vyatta.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: 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 13:50:34 -0700 [thread overview]
Message-ID: <20120627135034.7db7d0eb@nehalam.linuxnetplumber.net> (raw)
In-Reply-To: <1340829541.26242.90.camel@edumazet-glaptop>
On Wed, 27 Jun 2012 22:39:01 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> All sane SNMP applications are ready to cope with 32bits counters
> wrapping.
Actually that statement depends on the data rate. SNMP daemons work
by polling at periodic intervals. The limit for detecting roll over depends
on the rate and the interval. I believe the ubiquitous net-snmp code uses
something a 30 second polling interval for lots of it's caches. This means
it rolls over too fast at 10G. Polling faster can help but net-snmp is
a pig about updates.
I just realized the whole x32 (running 32 bit apps on 64 bit kernel) is broken
for things like /proc/net/dev where 64 bit kernel will give 64 bit values and
the 32 bit app (like net-snmp) is expecting unsigned long (32 bits).
next prev parent reply other threads:[~2012-06-27 20:50 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 [this message]
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
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=20120627135034.7db7d0eb@nehalam.linuxnetplumber.net \
--to=shemminger@vyatta.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=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.