mac80211 does the same afterwards anyway. Hence, just drop
this redundant code.
Signed-off-by: Helmut Schaa <[email protected]>
---
net/mac80211/rc80211_minstrel_ht.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index 165a451..775cf15 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -519,9 +519,7 @@ minstrel_ht_set_rate(struct minstrel_priv *mp, struct minstrel_ht_sta *mi,
rate->count = mr->retry_count;
rate->flags = IEEE80211_TX_RC_MCS | group->flags;
- if (txrc->short_preamble)
- rate->flags |= IEEE80211_TX_RC_USE_SHORT_PREAMBLE;
- if (txrc->rts || rtscts)
+ if (rtscts)
rate->flags |= IEEE80211_TX_RC_USE_RTS_CTS;
rate->idx = index % MCS_GROUP_RATES + (group->streams - 1) * MCS_GROUP_RATES;
}
--
1.7.1
Devices without multi rate retry support won't be able to use all rates
as specified by mintrel_ht. Hence, we can simply skip setting up further
rates as the devices will only use the first one.
Signed-off-by: Helmut Schaa <[email protected]>
---
has_mrr is true if the device is able to make use of at least four rates. Not
sure if we might want to consider further special cases for devices with for
example a maximum of two rates.
Tested with rt2800pci.
net/mac80211/rc80211_minstrel_ht.c | 24 +++++++++++++++++-------
1 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index 775cf15..6010a5b 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -603,19 +603,29 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
sample = true;
minstrel_ht_set_rate(mp, mi, &ar[0], sample_idx,
txrc, true, false);
- minstrel_ht_set_rate(mp, mi, &ar[1], mi->max_tp_rate,
- txrc, false, false);
info->flags |= IEEE80211_TX_CTL_RATE_CTRL_PROBE;
} else {
minstrel_ht_set_rate(mp, mi, &ar[0], mi->max_tp_rate,
txrc, false, false);
- minstrel_ht_set_rate(mp, mi, &ar[1], mi->max_tp_rate2,
- txrc, false, true);
}
- minstrel_ht_set_rate(mp, mi, &ar[2], mi->max_prob_rate, txrc, false, !sample);
- ar[3].count = 0;
- ar[3].idx = -1;
+ if (mp->has_mrr) {
+ if (sample_idx >= 0)
+ minstrel_ht_set_rate(mp, mi, &ar[1], mi->max_tp_rate,
+ txrc, false, false);
+ else
+ minstrel_ht_set_rate(mp, mi, &ar[1], mi->max_tp_rate2,
+ txrc, false, true);
+
+ minstrel_ht_set_rate(mp, mi, &ar[2], mi->max_prob_rate, txrc, false, !sample);
+
+ ar[3].count = 0;
+ ar[3].idx = -1;
+ } else {
+ /* Not using MRR, only use the first rate */
+ ar[1].count = 0;
+ ar[1].idx = -1;
+ }
mi->total_packets++;
--
1.7.1
On 2011-03-04 1:31 PM, Helmut Schaa wrote:
> Devices without multi rate retry support won't be able to use all rates
> as specified by mintrel_ht. Hence, we can simply skip setting up further
> rates as the devices will only use the first one.
>
> Signed-off-by: Helmut Schaa <[email protected]>
> ---
>
> has_mrr is true if the device is able to make use of at least four rates. Not
> sure if we might want to consider further special cases for devices with for
> example a maximum of two rates.
I think we should add a special case for handling a maximum of two
rates. Right now this is being used by brcm80211, so applying this patch
might make things worse there.
- Felix
On 2011-03-04 6:23 PM, Helmut Schaa wrote:
> Am Freitag, 4. M?rz 2011 schrieb Felix Fietkau:
>> On 2011-03-04 1:31 PM, Helmut Schaa wrote:
>> > Devices without multi rate retry support won't be able to use all rates
>> > as specified by mintrel_ht. Hence, we can simply skip setting up further
>> > rates as the devices will only use the first one.
>> >
>> > Signed-off-by: Helmut Schaa <[email protected]>
>> > ---
>> >
>> > has_mrr is true if the device is able to make use of at least four rates. Not
>> > sure if we might want to consider further special cases for devices with for
>> > example a maximum of two rates.
>> I think we should add a special case for handling a maximum of two
>> rates. Right now this is being used by brcm80211, so applying this patch
>> might make things worse there.
>
> John, please drop this patch then.
>
> Felix, currently minstrel_ht uses a maximum of 3 rates as far as I can see.
>
> In the sampling case it's
> sample_rate -> highest_tp_rate -> highest_prob_rate
> and in the default case it's
> highest_tp_rate -> second_highest_tp_rate -> highest_prob_rate
>
> For devices with just one possible rate it would be either the sample_rate
> or the highest_tp_rate.
>
> And for devices with two rates it might make sense to change the logic to
> something like
> sample_rate -> highest_prob_rate
> and
> highest_tp_rate -> highest_prob_rate
>
> Does that sound reasonable?
Yes, sounds good.
- Felix
On 2011-03-04 1:31 PM, Helmut Schaa wrote:
> mac80211 does the same afterwards anyway. Hence, just drop
> this redundant code.
>
> Signed-off-by: Helmut Schaa <[email protected]>
Acked-by: Felix Fietkau <[email protected]>
Am Freitag, 4. M?rz 2011 schrieb Felix Fietkau:
> On 2011-03-04 1:31 PM, Helmut Schaa wrote:
> > Devices without multi rate retry support won't be able to use all rates
> > as specified by mintrel_ht. Hence, we can simply skip setting up further
> > rates as the devices will only use the first one.
> >
> > Signed-off-by: Helmut Schaa <[email protected]>
> > ---
> >
> > has_mrr is true if the device is able to make use of at least four rates. Not
> > sure if we might want to consider further special cases for devices with for
> > example a maximum of two rates.
> I think we should add a special case for handling a maximum of two
> rates. Right now this is being used by brcm80211, so applying this patch
> might make things worse there.
John, please drop this patch then.
Felix, currently minstrel_ht uses a maximum of 3 rates as far as I can see.
In the sampling case it's
sample_rate -> highest_tp_rate -> highest_prob_rate
and in the default case it's
highest_tp_rate -> second_highest_tp_rate -> highest_prob_rate
For devices with just one possible rate it would be either the sample_rate
or the highest_tp_rate.
And for devices with two rates it might make sense to change the logic to
something like
sample_rate -> highest_prob_rate
and
highest_tp_rate -> highest_prob_rate
Does that sound reasonable?
Thanks,
Helmut