Re: Per MLO link TX stats

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2024-08-27 at 09:12 -0700, Ben Greear wrote:
> 
> When be200 goes into eMLSR mode, both 5 and 6Ghz links are shown as active, so at least
> you cannot use 'active link' to reliably update stats.

Sure, not active link - but there's an LMAC bit somewhere ... Ah, it's
not documented, it's actually documented *differently*, but it should be
bit 31 in len_n_flags in struct iwl_rx_packet.

Given the LMAC ID on the TX response notification we should know which
LMAC transmitted it, and then I think it's a simple mapping to the
active link. But I haven't actually really tried it.

> > > In the case where there is a single active link, then I can hack something together
> > > that should be at least mostly right, but that won't fix any future radio that can
> > > do 2+ active links.
> > > 
> > > Any suggestions for best path forward on this?
> > 
> > I really think we also need to do some work on the API/cfg80211 level,
> > and have link station statistics in cfg80211 instead of full station,
> > and then combine them to (older) userspace in cfg80211, i.e. if
> > userspace doesn't request broken out per-link statistics. There's
> > probably a bunch of work here, and I only have a vague idea of how it
> > should be done...
> 
> I think first step is to get the driver(s) able to report the link-id in
> the tx-status.  After that, mac80211 can gather the stats.  

Yeah, that makes sense, at least partially that's needed. I suspect that
also we need to extend the API down to the sta_statistics call though to
return per-link statistics, e.g. the TX bitrate would seem should be
reported per link, and that's done through that call now I believe.

> I hacked
> tx/rx link stats into mac80211 ethtool (for first 3 links), but it is still not reliable since
> mac80211 doesn't know the actual tx link id.

Right.

> After that, then certainly I'd be happy to have per-link stats available,
> and combining them in cfg80211 seems like a fine idea as well.  Some things
> that don't combine well (rssi, link rates, etc) would take a bit of kludging
> if trying to provide a single 'sta' view of stats.

True, some can't just be added up and we'd have to find a sane different
"best" view, perhaps for rates it'd be the better of the two or the sum
if only reporting the bitrate, or better of the RSSI, etc. Case by case,
I guess.

johannes