From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from smtp.codeaurora.org ([198.145.29.96]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1f7xf3-0005O2-7A for ath10k@lists.infradead.org; Mon, 16 Apr 2018 06:30:46 +0000 MIME-Version: 1.0 Date: Mon, 16 Apr 2018 12:00:32 +0530 From: akolli@codeaurora.org Subject: Re: [PATCH v2] ath10k: Implement get_expected_throughput callback In-Reply-To: References: <1521814034-17880-1-git-send-email-akolli@codeaurora.org> <2322769.sx4MhzsvNg@bentobox> <7428dc3685e146dca147805b6a1bc5d2@codeaurora.org> <1580002.5HauTVtcdp@bentobox> <87lgdrqkst.fsf@kamboji.qca.qualcomm.com> Message-ID: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Peter Oh Cc: Marek Lindner , Johannes Berg , linux-wireless-owner@vger.kernel.org, linux-wireless@vger.kernel.org, Antonio Quartulli , ath10k@lists.infradead.org, Sven Eckelmann , Kalle Valo , Felix Fietkau On 2018-04-14 01:54, Peter Oh wrote: > On 04/13/2018 06:48 AM, Kalle Valo wrote: >> Sven Eckelmann writes: >> >>> But of course, I cannot say much about how the rate control from QCA >>> works and >>> in which form these information are already available. >>> >>> If you want to know the average PHY rate then wouldn't it be better >>> to report >>> the rates to one of the upper layers and let them to the averaging? >>> Similar to >>> what there already is for NL80211_STA_INFO_CHAIN_SIGNAL >>> (NL80211_STA_INFO_CHAIN_SIGNAL_AVG) just for >>> NL80211_STA_INFO_TX_BITRATE/ >>> NL80211_STA_INFO_RX_BITRATE. Not sure whether this makes sense or >>> whether >>> someone has an use-case for it. >> Sounds like a good idea, but I don't see it preventing to apply this >> patch. We can always change the implementation later as this is just >> communication between ath10k and mac80211, right? >> > I agree with Sven on the usage or expectation of > get_expected_throughput cabllback. > It's not really ab expected throughput implementation. > However I'm with Kalle about approving this patch as Sven also > mentioned "here sounds a little bit like in "Our medical doctor would > ideally not decapitate each patient but we have at least an MD"". > I could improve it once merged since there are more members in > ath10k_per_peer_tx_stats useful such as succ_bytes, failed_bytes, > duration, and etc. On each packet sent successfully, driver has the success_bytes details. Throughput calculation can be done using these bytes and tx rate (tx_rate * bytes), send this average value to mac80211. is this you are thinking of? Thanks, Anil. _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k