mbox series

[net-next,v2,0/3] net: core: Unify dstats with tstats and lstats, add generic collection helper

Message ID 20240605-dstats-v2-0-7fae03f813f3@codeconstruct.com.au (mailing list archive)
Headers show
Series net: core: Unify dstats with tstats and lstats, add generic collection helper | expand

Message

Jeremy Kerr June 5, 2024, 9:42 a.m. UTC
The struct pcpu_dstats ("dstats") has a few variations from the other
two stats types (struct pcpu_sw_netstats and struct pcpu_lstats), and
doesn't have generic helpers for collecting the per-cpu stats into a
struct rtnl_link_stats64.

This change unifies dstats with the other types, adds a collection
helper (dev_get_dstats64) for ->ndo_get_stats64, and updates the single
driver (vrf) to use this helper.

Of course, questions/comments/etc are most welcome!

Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
---
v2:
- use correct percpu var in dev_fetch_dstats
- use correct accessor in vfr rx drop accounting
- Link to v1: https://lore.kernel.org/r/20240605-dstats-v1-0-1024396e1670@codeconstruct.com.au

---
Jeremy Kerr (3):
      net: core,vrf: Change pcpu_dstat fields to u64_stats_t
      net: core: Implement dstats-type stats collections
      net: vrf: move to generic dstat helpers

 drivers/net/vrf.c         | 57 +++++++++++++++--------------------------------
 include/linux/netdevice.h | 15 ++++++++-----
 net/core/dev.c            | 56 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 83 insertions(+), 45 deletions(-)
---
base-commit: 32f88d65f01bf6f45476d7edbe675e44fb9e1d58
change-id: 20240605-dstats-b6e08c318555

Best regards,

Comments

Jakub Kicinski June 6, 2024, 2:02 a.m. UTC | #1
On Wed, 05 Jun 2024 17:42:56 +0800 Jeremy Kerr wrote:
> This change unifies dstats with the other types, adds a collection
> helper (dev_get_dstats64) for ->ndo_get_stats64, and updates the single
> driver (vrf) to use this helper.

I think you can go further, instead of exporting the helpers and
hooking them in the driver, just add the handling based on
pcpu_stat_type directly in dev_get_stats().
Jeremy Kerr June 6, 2024, 2:11 a.m. UTC | #2
Hi Jakub,

> > This change unifies dstats with the other types, adds a collection
> > helper (dev_get_dstats64) for ->ndo_get_stats64, and updates the
> > single
> > driver (vrf) to use this helper.
> 
> I think you can go further, instead of exporting the helpers and
> hooking them in the driver, just add the handling based on
> pcpu_stat_type directly in dev_get_stats().

OK, makes sense!

If we're not exporting the helpers, that means that drivers that use
dstats wouldn't have a facility to customise the stats collection
through a ndo_get_stats64() callback though (as can be done with
tstats). Are you ok with that?

[the set of drivers that need that is currently zero, so more of a
hypothetical future problem...]

Cheers,


Jeremy
Jakub Kicinski June 6, 2024, 2:18 a.m. UTC | #3
On Thu, 06 Jun 2024 10:11:51 +0800 Jeremy Kerr wrote:
> If we're not exporting the helpers, that means that drivers that use
> dstats wouldn't have a facility to customise the stats collection
> through a ndo_get_stats64() callback though (as can be done with
> tstats). Are you ok with that?
> 
> [the set of drivers that need that is currently zero, so more of a
> hypothetical future problem...]

Right, but I think "no exports unless there is an in-tree user"
is still a rule. A bit of a risk that someone will roll their own
per-cpu stats pointlessly if we lack this export. But let's try
to catch that in review..
Jeremy Kerr June 6, 2024, 3:01 a.m. UTC | #4
Hi Jakub,

> > If we're not exporting the helpers, that means that drivers that
> > use
> > dstats wouldn't have a facility to customise the stats collection
> > through a ndo_get_stats64() callback though (as can be done with
> > tstats). Are you ok with that?
> > 
> > [the set of drivers that need that is currently zero, so more of a
> > hypothetical future problem...]
> 
> Right, but I think "no exports unless there is an in-tree user"
> is still a rule. A bit of a risk that someone will roll their own
> per-cpu stats pointlessly if we lack this export. But let's try
> to catch that in review..

OK, sounds good! I'll send a v3 shortly.

Cheers,


Jeremy
Jakub Kicinski June 6, 2024, 3:08 a.m. UTC | #5
On Thu, 06 Jun 2024 11:01:01 +0800 Jeremy Kerr wrote:
> > Right, but I think "no exports unless there is an in-tree user"
> > is still a rule. A bit of a risk that someone will roll their own
> > per-cpu stats pointlessly if we lack this export. But let's try
> > to catch that in review..  
> 
> OK, sounds good! I'll send a v3 shortly.

About that.. :) We do advise to wait 24 hours before sending next
versions in case there is more feedback / someone disagrees:

https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#tl-dr
Jeremy Kerr June 6, 2024, 3:24 a.m. UTC | #6
Hi Jakub,

> > > Right, but I think "no exports unless there is an in-tree user"
> > > is still a rule. A bit of a risk that someone will roll their own
> > > per-cpu stats pointlessly if we lack this export. But let's try
> > > to catch that in review..  
> > 
> > OK, sounds good! I'll send a v3 shortly.
> 
> About that.. :) We do advise to wait 24 hours before sending next
> versions in case there is more feedback / someone disagrees:

OK, for large values of "shortly" then :D

(sorry, I got a bit enthusiastic about v2, given the brown-paper-bag
bug in v1)

Cheers,


Jeremy