Re: [PATCH v2 1/2] wifi: cfg80211/mac80211: Add support to rx retry stats

[Johannes Berg <johannes@sipsolutions.net>]

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