[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20201103090527.52543b8c@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date: Tue, 3 Nov 2020 09:05:27 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Heiner Kallweit <hkallweit1@...il.com>
Cc: Saeed Mahameed <saeed@...nel.org>,
David Miller <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Russell King <linux@...linux.org.uk>,
Florian Fainelli <f.fainelli@...il.com>,
Vladimir Oltean <olteanv@...il.com>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>
Subject: Re: [PATCH net-next 0/5] net: add and use dev_get_tstats64
On Tue, 3 Nov 2020 15:46:27 +0100 Heiner Kallweit wrote:
> On 02.11.2020 23:36, Saeed Mahameed wrote:
> > On Sun, 2020-11-01 at 13:33 +0100, Heiner Kallweit wrote:
> >> It's a frequent pattern to use netdev->stats for the less frequently
> >> accessed counters and per-cpu counters for the frequently accessed
> >> counters (rx/tx bytes/packets). Add a default ndo_get_stats64()
> >> implementation for this use case. Subsequently switch more drivers
> >> to use this pattern.
> >>
> >> Heiner Kallweit (5):
> >> net: core: add dev_get_tstats64 as a ndo_get_stats64 implementation
> >> net: make ip_tunnel_get_stats64 an alias for dev_get_tstats64
> >> ip6_tunnel: use ip_tunnel_get_stats64 as ndo_get_stats64 callback
> >> net: dsa: use net core stats64 handling
> >> tun: switch to net core provided statistics counters
> >>
> >
> > not many left,
> >
> > $ git grep dev_fetch_sw_netstats drivers/
> >
> > drivers/infiniband/hw/hfi1/ipoib_main.c: dev_fetch_sw_netstats(s
> > torage, priv->netstats);
> > drivers/net/macsec.c: dev_fetch_sw_netstats(s, dev->tstats);
> > drivers/net/usb/qmi_wwan.c: dev_fetch_sw_netstats(stats, priv-
> >> stats64);
> > drivers/net/usb/usbnet.c: dev_fetch_sw_netstats(stats, dev-
> >> stats64);
> > drivers/net/wireless/quantenna/qtnfmac/core.c: dev_fetch_sw_netstats(s
> > tats, vif->stats64);
> >
> > Why not convert them as well ?
> > macsec has a different implementation, but all others can be converted.
> >
> OK, I can do this. Then the series becomes somewhat bigger.
> @Jakub: Would it be ok to apply the current series and I provide the
> additionally requested migrations as follow-up series?
Fine by me.
Powered by blists - more mailing lists