Received-SPF: pass (google.com: domain of linux-wireless+bounces-5479-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <4d569d40-d0a8-10d5-7e6d-4c9c03c14371@quicinc.com>
Date: Thu, 28 Mar 2024 22:49:16 +0530
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: [PATCH v2 1/2] wifi: cfg80211/mac80211: Add support to rx retry
 stats
Content-Language: en-US
To: Johannes Berg <johannes@sipsolutions.net>,
        Jeff Johnson
	<quic_jjohnson@quicinc.com>,
        <ath11k@lists.infradead.org>
CC: <linux-wireless@vger.kernel.org>
References: <20240319134522.4021062-1-quic_haric@quicinc.com>
 <20240319134522.4021062-2-quic_haric@quicinc.com>
 <d364e872eb29f03236630bab49a3243e2118ab22.camel@sipsolutions.net>
 <14699537-99b2-e468-6a7b-7b721193400e@quicinc.com>
 <b9dfab64822bacf0cc72380c0de034b79d489668.camel@sipsolutions.net>
 <68c6fcbd-0aaa-43b2-b5e2-08367c11e79d@quicinc.com>
 <f5cb9edcea875920e0ce156be76d06c78d1279ec.camel@sipsolutions.net>
From: Hari Chandrakanthan <quic_haric@quicinc.com>
In-Reply-To: <f5cb9edcea875920e0ce156be76d06c78d1279ec.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit


On 3/27/2024 8:37 PM, Johannes Berg wrote:
> 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.
The statistics can be populated by driver or mac80211.(say tx retries, 
tx packets etc)
So we should also change the existing stats update in mac80211 on link 
STA basis instead of deflink?
>> 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?

ok. Then the statistics value in MLD STA would be bias + summed up value 
of currently alive links?

On the same line , ethtool stats(*interface level stats*) in 
mac80211(ieee80211_get_stats())
computes the stats by summing up the current STA statistics.
Here stations can come and go and the ethtool stats may not reflect the 
total packets transmitted or received by the interface.
It just reflects the summed up value of current alive stations.

Since these two problems are similar (ethtool stats and MLD stats 
calculation),
would like to understand what type of value would be more useful to user?

> johannes