From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ben Greear <greearb@candelatech.com>
Cc: David Miller <davem@davemloft.net>,
Patrick McHardy <kaber@trash.net>,
netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH] macvlan: lockless tx path
Date: Wed, 10 Nov 2010 23:21:45 +0100 [thread overview]
Message-ID: <1289427705.17691.52.camel@edumazet-laptop> (raw)
In-Reply-To: <4CDB1021.507@candelatech.com>
Le mercredi 10 novembre 2010 à 13:35 -0800, Ben Greear a écrit :
> So an application that must deal with wraps must poll at the minimal
> time interval for wrapping 32-bit counters at whatever speed, or it
> must pay attention to the driver to somehow know that this magic driver
> can *really* do 64-bit stats properly?
>
Are you aware that you speak of something that is not specified at all
in linux ?
Frequency of polling is not part of any RFC. This usually is tunable in
the _application_. Some people sample stats every 5 minutes, some sample
every second, and hit the "xxx driver updates its stats every two
seconds, this sucks"
I wrote SNMP apps based on /proc/net/dev and all just work, with any
versions, any driver. Of course, some of them broke 6 years ago because
they were 32bit legacy application, running on a 64bit kernel. I never
asked David to change /proc/net/dev to cap counters to 32bit.
When 128bit cpu come, some userland changes are needed to parse 128bit
numbers.
In anycase, apps dont have to know a particular driver provides 64bit or
32bit counter. Only choice for them is to automatically detect the
wraparound, because they fetch a STRING, not a Counter32 or Counter64
This works for all drivers, legacy, new, Intel or whatever. If a driver
changes from 32 to 64, nothing special happens in /proc/net/dev.
RRD for example handles this just fine.
> Please note that just because a counter is less than the previous read,
> that doesn't by itself tell us if it wrapped once or twice. And, if we
> don't know at which number of bits it wraps, then we don't know how many
> to add even if we are certain it wrapped only once.
>
I repeat : Nothing in /proc/net/dev can tell you when a counter will
wrap (the counter width).
You also need to use the correct polling frequency, depending on max
speed. It was already the case with 32bit counters, 64bit ones only gave
some extra range.
> In general, I want to treat eth0 the same as eth5, and not worry that one
> is 10/100 realtek and the other a 10G Intel.
>
> If netlink reports stats64, then those should only wrap at 64 bits,
> and if it reports stats32, then wrap at 32-bits.
>
I believe you are mistaken. We provide stats64 for all drivers, even
32bit legacy ones. rtnetlink has no way to report counter widths,
because nobody cared.
next prev parent reply other threads:[~2010-11-10 22:21 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-10 15:41 [PATCH] macvlan: lockless tx path Eric Dumazet
2010-11-10 17:39 ` Ben Greear
2010-11-10 17:43 ` Eric Dumazet
2010-11-10 17:53 ` Ben Greear
2010-11-10 18:18 ` Eric Dumazet
2010-11-10 18:40 ` Ben Greear
2010-11-10 20:33 ` Eric Dumazet
2010-11-10 21:04 ` Ben Hutchings
2010-11-10 21:12 ` Eric Dumazet
2010-11-10 21:53 ` Ben Hutchings
2010-11-10 21:35 ` Ben Greear
2010-11-10 22:21 ` Eric Dumazet [this message]
2010-11-10 22:53 ` Ben Greear
2010-11-10 23:24 ` Eric Dumazet
2010-11-10 23:36 ` Eric Dumazet
2010-11-10 23:46 ` Ben Greear
2010-11-11 7:03 ` Eric Dumazet
2010-11-11 16:40 ` Ben Greear
2010-11-11 16:56 ` Eric Dumazet
2010-11-11 17:20 ` Ben Greear
2010-11-11 18:02 ` Eric Dumazet
2010-11-11 18:13 ` Ben Greear
2010-11-11 18:46 ` Eric Dumazet
2010-11-11 7:14 ` [PATCH net-next-2.6 v2] " Eric Dumazet
2010-11-12 8:20 ` Patrick McHardy
2010-11-16 18:59 ` 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=1289427705.17691.52.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=greearb@candelatech.com \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox