Re: [PATCH net-next v2 2/9] libeth: add common queue stats

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 28 Aug 2024 17:06:17 +0200 Alexander Lobakin wrote:
> >> The stats I introduced here are supported by most, if not every, modern
> >> NIC drivers. Not supporting header split or HW GRO will save you 16
> >> bytes on the queue struct which I don't think is a game changer.  
> > 
> > You don't understand. I built some infra over the last 3 years.
> > You didn't bother reading it. Now you pop our own thing to the side,
> > extending ethtool -S which is _unusable_ in a multi-vendor, production
> > environment.  
> 
> I read everything at the time you introduced it. I remember Ethernet
> standard stats, rmon, per-queue generic stats etc. I respect it and I
> like it.
> So just let me repeat my question so that all misunderstandings are
> gone: did I get it correctly that instead of adding Ethtool stats, I
> need to add new fields to the per-queue Netlink stats? I clearly don't
> have any issues with that and I'll be happy to drop Ethtool stats from
> the lib at all.

That's half of it, the other half is excess of macro magic.

> (except XDP stats, they still go to ethtool -S for now? Or should I try
> making them generic as well?)

Either way is fine by me. You may want to float the XDP stats first as
a smaller series, just extending the spec and exposing from some driver
already implementing qstat. In case someone else does object.

> >> * reduce boilerplate code in drivers: declaring stats structures,
> >> Ethtool stats names, all these collecting, aggregating etc etc, you see
> >> in the last commit of the series how many LoCs get deleted from idpf,
> >> +/- the same amount would be removed from any other driver  
> > 
> >  21 files changed, 1634 insertions(+), 1002 deletions(-)  
> 
> Did you notice my "in the last commit"?

I may not have. But as you said, most drivers end up with some level of
boilerplate around stats. So unless the stuff is used by more than one
driver, and the savings are realized, the argument about saving LoC has
to be heavily discounted. Queue xkcd 927. I should reiterate that 
I don't think LoC saving is a strong argument in the first place.