From: Heiner Kallweit <hkallweit1@gmail.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"andrew@lunn.ch" <andrew@lunn.ch>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
"vivien.didelot@gmail.com" <vivien.didelot@gmail.com>,
"kuba@kernel.org" <kuba@kernel.org>,
Christian Eggers <ceggers@arri.de>,
Kurt Kanzenbach <kurt@linutronix.de>
Subject: Re: [RFC PATCH 01/13] net: dsa: add plumbing for custom netdev statistics
Date: Sun, 18 Oct 2020 15:09:32 +0200 [thread overview]
Message-ID: <19f10bf4-4154-2207-6554-e44ba05eed8a@gmail.com> (raw)
In-Reply-To: <20201018121640.jwzj6ivpis4gh4ki@skbuf>
On 18.10.2020 14:16, Vladimir Oltean wrote:
> On Sun, Oct 18, 2020 at 02:02:46PM +0200, Heiner Kallweit wrote:
>> Wouldn't a simple unsigned long (like in struct net_device_stats) be
>> sufficient here? This would make handling the counter much simpler.
>> And as far as I understand we talk about a packet counter that is
>> touched in certain scenarios only.
>
> I don't understand, in what sense 'sufficient'? This counter is exported
> to ethtool which works with u64 values, how would an unsigned long,
> which is u32 on 32-bit systems, help?
>
Sufficient for me means that it's unlikely that a 32 bit counter will
overflow. Many drivers use the 32 bit counters (on a 32bit system) in
net_device_stats for infrequent events like rx/tx errors, and 64bit
counters only for things like rx/tx bytes, which are more likely to
overflow.
next prev parent reply other threads:[~2020-10-18 13:09 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-17 21:35 [RFC PATCH 00/13] Generic TX reallocation for DSA Vladimir Oltean
2020-10-17 21:35 ` [RFC PATCH 01/13] net: dsa: add plumbing for custom netdev statistics Vladimir Oltean
2020-10-17 22:13 ` Florian Fainelli
2020-10-17 23:15 ` Andrew Lunn
2020-10-18 0:23 ` Vladimir Oltean
2020-10-18 12:02 ` Heiner Kallweit
2020-10-18 12:16 ` Vladimir Oltean
2020-10-18 13:09 ` Heiner Kallweit [this message]
2020-10-18 13:48 ` Vladimir Oltean
2020-10-18 14:13 ` Heiner Kallweit
2020-10-18 22:58 ` Vladimir Oltean
2020-10-18 23:11 ` Florian Fainelli
2020-10-19 0:21 ` Vladimir Oltean
2020-10-19 3:49 ` Florian Fainelli
2020-10-19 12:05 ` Andrew Lunn
2020-10-19 16:27 ` Florian Fainelli
2020-10-18 16:49 ` Jakub Kicinski
2020-10-18 17:36 ` Andrew Lunn
2020-10-18 18:26 ` Jakub Kicinski
2020-10-18 18:33 ` Jakub Kicinski
2020-10-17 21:36 ` [RFC PATCH 02/13] net: dsa: implement a central TX reallocation procedure Vladimir Oltean
2020-10-17 22:01 ` Vladimir Oltean
2020-10-17 22:11 ` Florian Fainelli
2020-10-17 22:17 ` Vladimir Oltean
2020-10-18 0:37 ` Florian Fainelli
2020-10-19 8:33 ` David Laight
2020-10-19 10:30 ` Vladimir Oltean
2020-10-19 11:14 ` David Laight
2020-10-19 11:41 ` Vladimir Oltean
2020-10-19 12:19 ` Andrew Lunn
2020-10-17 22:31 ` Vladimir Oltean
2020-10-18 0:13 ` Vladimir Oltean
2020-10-18 10:36 ` Christian Eggers
2020-10-18 11:42 ` Vladimir Oltean
2020-10-18 11:59 ` Christian Eggers
2020-10-18 12:15 ` Vladimir Oltean
2020-10-17 21:36 ` [RFC PATCH 03/13] net: dsa: tag_ksz: don't allocate additional memory for padding/tagging Vladimir Oltean
2020-10-17 21:36 ` [RFC PATCH 04/13] net: dsa: trailer: " Vladimir Oltean
2020-10-17 21:36 ` [RFC PATCH 05/13] net: dsa: tag_qca: let DSA core deal with TX reallocation Vladimir Oltean
2020-10-17 21:36 ` [RFC PATCH 06/13] net: dsa: tag_ocelot: " Vladimir Oltean
2020-10-17 21:36 ` [RFC PATCH 07/13] net: dsa: tag_mtk: " Vladimir Oltean
2020-10-17 21:36 ` [RFC PATCH 08/13] net: dsa: tag_lan9303: " Vladimir Oltean
2020-10-17 21:36 ` [RFC PATCH 09/13] net: dsa: tag_edsa: " Vladimir Oltean
2020-10-17 21:36 ` [RFC PATCH 10/13] net: dsa: tag_brcm: " Vladimir Oltean
2020-10-17 21:36 ` [RFC PATCH 11/13] net: dsa: tag_dsa: " Vladimir Oltean
2020-10-17 21:36 ` [RFC PATCH 12/13] net: dsa: tag_gswip: " Vladimir Oltean
2020-10-17 22:19 ` Vladimir Oltean
2020-10-17 21:36 ` [RFC PATCH 13/13] net: dsa: tag_ar9331: " Vladimir Oltean
2020-10-17 23:07 ` [RFC PATCH 00/13] Generic TX reallocation for DSA Andrew Lunn
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=19f10bf4-4154-2207-6554-e44ba05eed8a@gmail.com \
--to=hkallweit1@gmail.com \
--cc=andrew@lunn.ch \
--cc=ceggers@arri.de \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=kurt@linutronix.de \
--cc=netdev@vger.kernel.org \
--cc=vivien.didelot@gmail.com \
--cc=vladimir.oltean@nxp.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.