On 7/1/22 6:08 AM, Johannes Berg wrote:
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?
A human looking at the value would be confused, but a program easily deals
with it. In a lot of ways, ethtool is way more straight forward to program
against than netlink, and it works well with non-wifi drivers, so one
chunk of stats-gathering code for all network devices.
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 :)
I've managed to mostly dodge it for 20 years....there is hope to make it another 20!
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 :)
Ok, I'll add that to my list and will plan to do it next time I rebase on
a newer upstream kernel.
Thanks,
Ben
johannes
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
