On Fri, 2022-07-01 at 06:05 -0700, Ben Greear wrote: > On 7/1/22 2:55 AM, Johannes Berg wrote: > > On Tue, 2022-03-29 at 14:02 -0700, greearb@xxxxxxxxxxxxxxx wrote: > > > From: Ben Greear <greearb@xxxxxxxxxxxxxxx> > > > > > > Combine them into a u64, each byte is one chain. > > > > This only works up to 4 chains, but the specs at least support 8. I > > don't think we have any drivers for that, but ... > > u64 gives 8 bytes, so the ethtool part can support 8 chains. > The mac80211 part only supports up to 4 chains currently though. Oops, right, sorry. Still, I'm not sure I like munging it all up into one value - the value itself then doesn't mean anything, and the normal ethtool APIs userspace tools would be pretty much useless for it? > > We're reporting these through nl80211 anyway though, no? Why should we > > prefer ethtool, which fundamentally limits to a single value for the AP > > rather than giving the full per-station view. > > I already gather ethtool stats for STA vdevs, so adding another stat is > basically free as far as performance is concerned. That is important > to me. I do not currently program much against netlink API (just scrape > existing tools output). Well I guess then I think you probably should program against the netlink API :) > > > Re-work the way that APs averaged stats to be more > > > efficient. > > > > Isn't that completely unrelated? > > At least somewhat unrelated. > Fair enough. Maybe send that separately? I guess that's something I'd understand a bit more and improving the existing code is an easier sell than adding a whole new thing there :) johannes
