On Wed, 2024-03-27 at 08:02 -0700, Jeff Johnson wrote: > > I'm also imagining that we change the API from cfg80211 to the drivers > > to get the *link* STA information, and do the summing up and/or "best" > > selection there in cfg80211 itself. However, I am prepared to accept the > > possibility that we may do _both_ in the API, if not all drivers can > > even do all of the statistics per link. We should probably still have > > the link STAs in the statistics in nl80211, but then they may not be > > populated? > > First remember that there are a lot of statistics, and each driver is free to > return as many or as few as they support, indicating the ones they are > returning using the "filled" bitmap. Yes, I'd think we want to use the same data structure for both, though setting something in *both* links and *mld* would (should) be an error. > I would expect MLO-capable drivers to > provide the same information on a per-link basis that they previously provided > on a per-interface basis, but the "filled" bitmap leaves that to the drivers. Unless we don't actually ask the drivers at the MLD level if (the station is an MLD). But I suspect we will have to do both, ask for MLD- level stats and link-level stats. > But I think a fundamental question needs to be answered: To what extent do we > need to support legacy userspace applications that are not MLO-aware? I have no idea who even uses this and how :-) But I guess things like NetworkManager might, even just to show some signal strength values etc.? > My expectation is that MLO-aware applications only need the per-link > information, and from that they can derive their own "aggregate" of the > per-link information. Agree, though it'll be a long time until all applications are MLO-aware? Unless there aren't many using it, but ... > So to support that we'd need per-link nesting of the > associated attributes. Sure, that's a given. > And if we don't need to support legacy userspace we > could completely remove populating the top-level statistic attributes. Non-MLO > interfaces would have a single link nest that contains the same information > that is now in the top-level of the NL message. > > But if we need to support legacy userspace then we would indeed need to > continue to populate those top-level attributes with some form of aggregate data. I think we probably have to. > And even for the MLO-aware case there is the issue of how do we want to handle > the case that links may come and go, and hence aggregate counters would appear > to have huge fluctuations in values when links are added or removed if the > aggregate values are only calculated by adding the values from the > currently-attached links. Good point, when they're really removed we'd want to probably keep that value as a bias for the MLD-level stats? johannes
