Received-SPF: pass (google.com: domain of linux-wireless+bounces-5320-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <b9dfab64822bacf0cc72380c0de034b79d489668.camel@sipsolutions.net>
Subject: Re: [PATCH v2 1/2] wifi: cfg80211/mac80211: Add support to rx retry
 stats
From: Johannes Berg <johannes@sipsolutions.net>
To: Hari Chandrakanthan <quic_haric@quicinc.com>, ath11k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Date: Wed, 27 Mar 2024 11:32:48 +0100
In-Reply-To: <14699537-99b2-e468-6a7b-7b721193400e@quicinc.com>
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.4 (3.50.4-1.fc39) 
Precedence: bulk
MIME-Version: 1.0

On Wed, 2024-03-27 at 15:39 +0530, Hari Chandrakanthan wrote:

> Fields such packet count, retries etc can be summed up for the MLD=20
> representation and the existing NL attribute can be used for exposing
> the summed up value.

I think the existing attributes can also be used for per-link STA?

I'm kind of imagining that - once we actually do all of this properly -
the representation in nl80211 would be something like


STA 00:00:00:00:00:00
 - TX bytes: 123456
 - RX bytes: 654321
 - signal avg: -60 dBm     // picking the best of all links?
 ...
 - LINK 00:00:00:00:00:01
    - link ID: 10
    - TX bytes: 100000
    - RX bytes: 600000
    - signal avg: -60 dBm
 - LINK 00:00:00:00:00:02
    - link ID: 11
    - TX bytes: 23456
    - RX bytes: 54321
    - signal avg: -70 dBm

etc.

> But there are fields such as signal avg, bitrate etc which cannot be=20
> summed up.

Right, but I guess we can pick 'best' for those, to at least have a
value? Or we could just not emit those attributes I guess, but not sure
if that's then all that useful?

> Should we expose such fields of each link STA through NL?

All of them, I guess?

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?

johannes