On 1/10/2025 10:23 PM, Ben Greear wrote:
On 1/9/25 20:24, Sarika Sharma wrote:
Current implementation of NL80211_CMD_GET_STATION does not work
for multi-link operation(MLO) since in case of MLO only deflink
(or one of the links) is considered and not all links.
Hence, add the link_sinfo structure to provide infrastructure
for link-level station statistics for multi-link operation(MLO).
Additionally, accumulated stats for MLO are included in a concise
manner to provide a comprehensive overview of the ML stations.
NOTE:
1. Current code changes are done to get an early feedback on design.
2. Once RFC patches are approved will add the required driver
changes.
3. Ath12k changes are included in this series for reference to other
driver changes.
Alternate approach:
- Keep sinfo structure as it is and use this for non-ML or
accumulated statistics for ML station.
- Add link sinfo for links with only certain link specific
statistics.
- Keep mac_op_sta_statistics at MLD level and let driver fill the
MLO and link level data, if driver not filling let mac80211 fill
the data.
- Corresponding changes done to embed statistics into the NL message
based on the sinfo/link_sinfo.
My suggestions for general approach to this:
1) current sinfo stats should report totals for all links,
but it should not sum them up at query time because links come
and go. So driver/firmware/mac80211 or whatever is keeping count
of the stats needs to count the total tx/rx/ packets/bytes/whatever
as it happens.
Alternate approach is not considered here, because some fields at
station level could not be much meaningful like rx_beacon, pertid ,etc.
I believe the total count is better to do from links data in
cfg80211/mac80211, as if link's data is provided it is easy to aggregate
them, during query time.
Also removed link_data is maintained in implemented approach, so that
could be helpful if any link go down.
2) Per-link stats can be over duration of the link object.
3) For sinfo logic that currently reports tx/rx mcs rate and such that
cannot
be summed, use 'best' link's for those values. Effectively, this
probably means highest
frequency is 'best' link.
Every fields have it's own way of best, so based on field need to check
what is best for this field value? but some parameters not have much
meaning at MLO level like rx_beacon, pertid, etc. So keeping best of it,
will be useful here?
or you mean need to check for best frequency link and take this link
data as MLO data? if yes? will it be useful here?
4) Add per-link stats data that looks very much like 'sinfo' data struct
and user-space
that can support that could then get detailed per-link stats at same
time it is getting
per netdev 'sinfo' stats.
Again, some fields that are in sinfo structure could not be very useful
at link level like generation, sta_info, etc. So keeping same structure
for station level and link level is not very useful, instead better to
split the structure, fields for station level and some fields at link level.
5) Assuming there will never be more than 3 links for any radios
supported by Linux in the near future,
embed the 3 link's 'sinfo-like' stats data structure in the per-netdev
sinfo stats struct
so that we can get all 3 link's data at same time that we are getting
the other stats.
That should save calls into the driver and ensure that per-links stats
can be gathered
at exactly the same time.
Yes, I agree currently it's 3 only, but everywhere we are using max-15,
so explicitly keeping it 3 here isn't questionable? In future also it
will not be useful.
Thanks,
Ben
Currently, addressing the comments on current implemented approach.
