From: Ben Greear <greearb@candelatech.com>
To: Johannes Berg <johannes@sipsolutions.net>,
linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: Per MLO link TX stats
Date: Tue, 27 Aug 2024 09:28:45 -0700 [thread overview]
Message-ID: <41008ac0-ca36-b19f-c3a4-61f54ce2d2f7@candelatech.com> (raw)
In-Reply-To: <9093726e308d0a26e8afe2323a865d222e48fe61.camel@sipsolutions.net>
On 8/27/24 09:20, Johannes Berg wrote:
> 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.
If you can share a patch that documents this bit (like 0 means 5Ghz and 1 means 6Ghz??)
then we can try it out.
And maybe your idea for how to report it in tx-status too since that will touch
mac80211?
>>>> 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.
Yes. At least at cfg80211 level, I think we should be able to query all
link stats in a single call into mac80211. Down in mac80211, then per-link
stats structs appears to be how things are done now and seems like a good
solution.
>
>> 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.
I'd suggest using highest active band when we have no better option for
summing/combining.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2024-08-27 16:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-12 17:52 Per MLO link TX stats Ben Greear
2024-08-27 15:56 ` Johannes Berg
2024-08-27 16:12 ` Ben Greear
2024-08-27 16:20 ` Johannes Berg
2024-08-27 16:28 ` Ben Greear [this message]
2024-08-27 16:41 ` Johannes Berg
2024-08-27 18:17 ` Ben Greear
2024-08-28 12:50 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41008ac0-ca36-b19f-c3a4-61f54ce2d2f7@candelatech.com \
--to=greearb@candelatech.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox