The sta->last_tx_rate is traditionally updated just before transmitting a
frame based on information from the rate control algorithm. However, for
hardware drivers with IEEE80211_HW_HAS_RATE_CONTROL this is not performed,
as the rate control algorithm is not executed, and because the used rate is
not known before the frame has actually been transmitted.
This causes atleast a fixed 1Mb/s to be reported to user space. A few other
instances of code also rely on this information.
Fix this by setting the sta->last_tx_rate in tx_status handling. There, look
for last rates entry set by the driver, and use that as value for
sta->last_tx_rate.
Signed-off-by: Juuso Oikarinen <[email protected]>
---
net/mac80211/status.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 11805a3..94613af 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -171,6 +171,7 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
struct net_device *prev_dev = NULL;
struct sta_info *sta, *tmp;
int retry_count = -1, i;
+ int rates_idx = -1;
bool send_to_cooked;
for (i = 0; i < IEEE80211_TX_MAX_RATES; i++) {
@@ -178,6 +179,8 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
if (i >= hw->max_rates) {
info->status.rates[i].idx = -1;
info->status.rates[i].count = 0;
+ } else if (info->status.rates[i].idx >= 0) {
+ rates_idx = i;
}
retry_count += info->status.rates[i].count;
@@ -206,6 +209,10 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
return;
}
+ if ((local->hw.flags & IEEE80211_HW_HAS_RATE_CONTROL) &&
+ (rates_idx != -1))
+ sta->last_tx_rate = info->status.rates[rates_idx];
+
if ((info->flags & IEEE80211_TX_STAT_AMPDU_NO_BACK) &&
(ieee80211_is_data_qos(fc))) {
u16 tid, ssn;
--
1.6.3.3
On Thu, Apr 22, 2010 at 12:27 AM, Juuso Oikarinen
<[email protected]> wrote:
> The sta->last_tx_rate is traditionally updated just before transmitting a
> frame based on information from the rate control algorithm. However, for
> hardware drivers with IEEE80211_HW_HAS_RATE_CONTROL this is not performed,
> as the rate control algorithm is not executed, and because the used rate is
> not known before the frame has actually been transmitted.
>
> This causes atleast a fixed 1Mb/s to be reported to user space. A few other
> instances of code also rely on this information.
>
> Fix this by setting the sta->last_tx_rate in tx_status handling. There, look
> for last rates entry set by the driver, and use that as value for
> sta->last_tx_rate.
>
> Signed-off-by: Juuso Oikarinen <[email protected]>
But the actual rate used is not known, or is it? In those cases would
it not be better to inform userspace that the information is not
available?
Luis
Hi,
On Thu, 2010-04-22 at 18:28 +0200, ext Luis R. Rodriguez wrote:
> On Thu, Apr 22, 2010 at 12:27 AM, Juuso Oikarinen
> <[email protected]> wrote:
> > The sta->last_tx_rate is traditionally updated just before transmitting a
> > frame based on information from the rate control algorithm. However, for
> > hardware drivers with IEEE80211_HW_HAS_RATE_CONTROL this is not performed,
> > as the rate control algorithm is not executed, and because the used rate is
> > not known before the frame has actually been transmitted.
> >
> > This causes atleast a fixed 1Mb/s to be reported to user space. A few other
> > instances of code also rely on this information.
> >
> > Fix this by setting the sta->last_tx_rate in tx_status handling. There, look
> > for last rates entry set by the driver, and use that as value for
> > sta->last_tx_rate.
> >
> > Signed-off-by: Juuso Oikarinen <[email protected]>
>
> But the actual rate used is not known, or is it? In those cases would
> it not be better to inform userspace that the information is not
> available?
The point here is to set the last_tx_rate with the actual used rate, as
reported by the hardware (and reported to mac80211 by the driver.)
In case of hardware rate control, mac80211 sets the skb's
info->status.rates array to rates indexes "-1".
The driver sets the rate actually used to transmit the frame into the
same array before calling tx_status, along with retry etc info, and
mac80211 then uses this info to update the sta->last_tx_rate.
So by all means, the actual rate is getting set. Opposite to host
rate-control, the sta->last_tx_rate field is just updated right after
transmitting the frame, instead of just before.
-Juuso
> Luis