From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3053DC54E67 for ; Wed, 27 Mar 2024 15:07:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:MIME-Version: Content-Transfer-Encoding:Content-Type:References:In-Reply-To:Date:Cc:To:From :Subject:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=mzk+bgPSkQUzL/vnXJBmrg/umyndJWoEggObcfG9yAE=; b=mLaRBZMeNcrHT0NjcFeQX9pMb7 GaWov8K0kR9MKpRvqoEEHiMwLEjUKkg4d/viX55kNx/nlIvffuaUit93OTzAkIgiyvh7WoB31KtiF ATTurg5FbkXmSQE3FyxtbaXhbKumsuXzhvEK1fn+WYxaczzGEkxgntNnzoALfMnLn5wDrv9Kz/+pc Dw4mTdvh89GZa8HBuHyMiiBrbd4GGmoHV7+2519sE0HVlCh6/Dq1j419C5b9t3vSJNfzkmpEHbPy6 sr87ZCcRG5DA3QlHQ9/hkpd0FBExEiamCRdggSleBCm/lUOdlGFN7zN25kQpE7EPD+RIszVbfnnUv 7QeSqhUQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rpUs0-00000009gbw-2ofx; Wed, 27 Mar 2024 15:07:16 +0000 Received: from s3.sipsolutions.net ([2a01:4f8:242:246e::2] helo=sipsolutions.net) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rpUry-00000009gat-2pai for ath11k@lists.infradead.org; Wed, 27 Mar 2024 15:07:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=MIME-Version:Content-Transfer-Encoding: Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=mzk+bgPSkQUzL/vnXJBmrg/umyndJWoEggObcfG9yAE=; t=1711552033; x=1712761633; b=E1MMNqjSRopPvXsX52/Wh7RseJW3s6POfTWLI5nxKLHu34H f8n1Cp3aivwjlgpUI5p9z7iA5wmYn1wDjvyiZlZMWpm+0sO5ULLivODlo0EIBhbTU2c3Rq+mi5Jns NxndtESakpvJrUNu9G39S9lkLu1rCgY4Ed4ZRjGEziuCBOJIxdUprCjr98sdnd2MHzmZIiVD4RkEM Z+PIKT2XbsPYe//z17BARM8aOjLm1+h5lJp7zN0t2IBWVQZn3XJEcgFGypbvmW/YdTuulI4k6WFeY mUjKLCMj5xfK1LR17Rbr0gcyM6edbk3T7xOKDmhK9YjYu1psM8gjTdXd2mGdnENg==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.97) (envelope-from ) id 1rpUru-0000000HAgP-26MD; Wed, 27 Mar 2024 16:07:10 +0100 Message-ID: Subject: Re: [PATCH v2 1/2] wifi: cfg80211/mac80211: Add support to rx retry stats From: Johannes Berg To: Jeff Johnson , Hari Chandrakanthan , ath11k@lists.infradead.org Cc: linux-wireless@vger.kernel.org Date: Wed, 27 Mar 2024 16:07:09 +0100 In-Reply-To: <68c6fcbd-0aaa-43b2-b5e2-08367c11e79d@quicinc.com> References: <20240319134522.4021062-1-quic_haric@quicinc.com> <20240319134522.4021062-2-quic_haric@quicinc.com> <14699537-99b2-e468-6a7b-7b721193400e@quicinc.com> <68c6fcbd-0aaa-43b2-b5e2-08367c11e79d@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) MIME-Version: 1.0 X-malware-bazaar: not-scanned X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240327_080714_733853_39B969CB X-CRM114-Status: GOOD ( 24.95 ) X-BeenThere: ath11k@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "ath11k" Errors-To: ath11k-bounces+ath11k=archiver.kernel.org@lists.infradead.org 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 th= e > > 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? >=20 > First remember that there are a lot of statistics, and each driver is fre= e to > return as many or as few as they support, indicating the ones they are > returning using the "filled" bitmap.=C2=A0 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 pro= vided > on a per-interface basis, but the "filled" bitmap leaves that to the driv= ers. 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 d= o 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. No= n-MLO > interfaces would have a single link nest that contains the same informati= on > that is now in the top-level of the NL message. >=20 > 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 aggrega= te data. I think we probably have to. > And even for the MLO-aware case there is the issue of how do we want to h= andle > the case that links may come and go, and hence aggregate counters would a= ppear > to have huge fluctuations in values when links are added or removed if th= e > 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