From: akolli@codeaurora.org
To: Peter Oh <peter.oh@bowerswilkins.com>
Cc: Marek Lindner <mareklindner@neomailbox.ch>,
Johannes Berg <johannes.berg@intel.com>,
linux-wireless-owner@vger.kernel.org,
linux-wireless@vger.kernel.org, Antonio Quartulli <a@unstable.cc>,
ath10k@lists.infradead.org,
Sven Eckelmann <sven.eckelmann@openmesh.com>,
Kalle Valo <kvalo@codeaurora.org>, Felix Fietkau <nbd@nbd.name>
Subject: Re: [PATCH v2] ath10k: Implement get_expected_throughput callback
Date: Mon, 16 Apr 2018 12:00:32 +0530 [thread overview]
Message-ID: <a42e9e3f2988c21d2b60af3d99489b62@codeaurora.org> (raw)
In-Reply-To: <f028b45d-8a2d-97f6-5eb9-fdb071a51e4d@bowerswilkins.com>
On 2018-04-14 01:54, Peter Oh wrote:
> On 04/13/2018 06:48 AM, Kalle Valo wrote:
>> Sven Eckelmann <sven.eckelmann@openmesh.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: akolli@codeaurora.org
To: Peter Oh <peter.oh@bowerswilkins.com>
Cc: Kalle Valo <kvalo@codeaurora.org>,
Sven Eckelmann <sven.eckelmann@openmesh.com>,
Marek Lindner <mareklindner@neomailbox.ch>,
Johannes Berg <johannes.berg@intel.com>,
linux-wireless@vger.kernel.org, Antonio Quartulli <a@unstable.cc>,
ath10k@lists.infradead.org, Felix Fietkau <nbd@nbd.name>,
linux-wireless-owner@vger.kernel.org
Subject: Re: [PATCH v2] ath10k: Implement get_expected_throughput callback
Date: Mon, 16 Apr 2018 12:00:32 +0530 [thread overview]
Message-ID: <a42e9e3f2988c21d2b60af3d99489b62@codeaurora.org> (raw)
In-Reply-To: <f028b45d-8a2d-97f6-5eb9-fdb071a51e4d@bowerswilkins.com>
On 2018-04-14 01:54, Peter Oh wrote:
> On 04/13/2018 06:48 AM, Kalle Valo wrote:
>> Sven Eckelmann <sven.eckelmann@openmesh.com> 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.
next prev parent reply other threads:[~2018-04-16 6:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-23 14:07 [PATCH v2] ath10k: Implement get_expected_throughput callback Anilkumar Kolli
2018-03-23 14:07 ` Anilkumar Kolli
2018-03-26 7:22 ` Sven Eckelmann
2018-03-26 7:22 ` Sven Eckelmann
2018-03-28 6:11 ` akolli
2018-03-28 6:11 ` akolli
2018-03-28 6:37 ` Sven Eckelmann
2018-03-28 6:37 ` Sven Eckelmann
2018-04-13 2:22 ` Peter Oh
2018-04-13 2:22 ` Peter Oh
2018-04-13 13:48 ` Kalle Valo
2018-04-13 13:48 ` Kalle Valo
2018-04-13 20:24 ` Peter Oh
2018-04-13 20:24 ` Peter Oh
2018-04-16 6:30 ` akolli [this message]
2018-04-16 6:30 ` akolli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a42e9e3f2988c21d2b60af3d99489b62@codeaurora.org \
--to=akolli@codeaurora.org \
--cc=a@unstable.cc \
--cc=ath10k@lists.infradead.org \
--cc=johannes.berg@intel.com \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless-owner@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mareklindner@neomailbox.ch \
--cc=nbd@nbd.name \
--cc=peter.oh@bowerswilkins.com \
--cc=sven.eckelmann@openmesh.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.