[PATCH 2/2] ath9k: Choose highest rate of MRR based on IEEE80211_TX_CTL_USE_MINRATE

[PATCH 2/2] ath9k: Choose highest rate of MRR based on IEEE80211_TX_CTL_USE_MINRATE

[Rajkumar Manoharan]

Select appropriate rate as highest rate of rate series, if the frame
was asked to be sent at minimum rate. For example nullfunc frames
either can be sent at HT rates on normal case or at non-HT rates if
it is used for connection monitoring.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath9k/rc.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/rc.c b/drivers/net/wireless/ath/ath9k/rc.c
index 8448281..3509f14 100644
--- a/drivers/net/wireless/ath/ath9k/rc.c
+++ b/drivers/net/wireless/ath/ath9k/rc.c
@@ -789,8 +789,8 @@ static void ath_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
 	try_per_rate = 4;
 
 	rate_table = ath_rc_priv->rate_table;
-	rix = ath_rc_get_highest_rix(sc, ath_rc_priv, rate_table,
-				     &is_probe, false);
+	rix = ath_rc_get_highest_rix(sc, ath_rc_priv, rate_table, &is_probe,
+			     !!(tx_info->flags & IEEE80211_TX_CTL_USE_MINRATE));
 	high_rix = rix;
 
 	/*
-- 
1.7.6.4

Re: [PATCH 2/2] ath9k: Choose highest rate of MRR based on IEEE80211_TX_CTL_USE_MINRATE

[Felix Fietkau]

On 2011-09-29 1:24 PM, Rajkumar Manoharan wrote:
> Select appropriate rate as highest rate of rate series, if the frame
> was asked to be sent at minimum rate. For example nullfunc frames
> either can be sent at HT rates on normal case or at non-HT rates if
> it is used for connection monitoring.
>
> Signed-off-by: Rajkumar Manoharan<rmanohar@qca.qualcomm.com>
> ---
>   drivers/net/wireless/ath/ath9k/rc.c |    4 ++--
>   1 files changed, 2 insertions(+), 2 deletions(-)
>
Shouldn't the check for IEEE80211_TX_CTL_USE_MINRATE be in 
rate_control_send_low(), so that it does not have to be repeated in 
every single rate control module?

- Felix

Re: [PATCH 2/2] ath9k: Choose highest rate of MRR based on IEEE80211_TX_CTL_USE_MINRATE

[Rajkumar Manoharan]

On Thu, Sep 29, 2011 at 01:32:03PM +0200, Felix Fietkau wrote:
> On 2011-09-29 1:24 PM, Rajkumar Manoharan wrote:
> >Select appropriate rate as highest rate of rate series, if the frame
> >was asked to be sent at minimum rate. For example nullfunc frames
> >either can be sent at HT rates on normal case or at non-HT rates if
> >it is used for connection monitoring.
> >
> >Signed-off-by: Rajkumar Manoharan<rmanohar@qca.qualcomm.com>
> >---
> >  drivers/net/wireless/ath/ath9k/rc.c |    4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> >
> Shouldn't the check for IEEE80211_TX_CTL_USE_MINRATE be in
> rate_control_send_low(), so that it does not have to be repeated in
> every single rate control module?
>
But I donno what could be the side effect of changing rate_control_send_low
as it is used by all drivers. And also if the rate control provide the
minrate, it can be used to update the PER upon tx status. isnt it?

--
Rajkumar

Re: [PATCH 2/2] ath9k: Choose highest rate of MRR based on IEEE80211_TX_CTL_USE_MINRATE

[Felix Fietkau]

On 2011-09-29 2:14 PM, Rajkumar Manoharan wrote:
> On Thu, Sep 29, 2011 at 01:32:03PM +0200, Felix Fietkau wrote:
>>  On 2011-09-29 1:24 PM, Rajkumar Manoharan wrote:
>>  >Select appropriate rate as highest rate of rate series, if the frame
>>  >was asked to be sent at minimum rate. For example nullfunc frames
>>  >either can be sent at HT rates on normal case or at non-HT rates if
>>  >it is used for connection monitoring.
>>  >
>>  >Signed-off-by: Rajkumar Manoharan<rmanohar@qca.qualcomm.com>
>>  >---
>>  >   drivers/net/wireless/ath/ath9k/rc.c |    4 ++--
>>  >   1 files changed, 2 insertions(+), 2 deletions(-)
>>  >
>>  Shouldn't the check for IEEE80211_TX_CTL_USE_MINRATE be in
>>  rate_control_send_low(), so that it does not have to be repeated in
>>  every single rate control module?
>>
> But I donno what could be the side effect of changing rate_control_send_low
> as it is used by all drivers. And also if the rate control provide the
> minrate, it can be used to update the PER upon tx status. isnt it?
It always updates the PER upon tx status, even if rate_control_send_low 
was used. It should work the same way for every driver, so I think 
putting this in the ath9k rc is the wrong place, and it would be weird 
if a flag with such a generic name as IEEE80211_TX_CTL_USE_MINRATE would 
be used by some rate control modules and ignored by others.

- Felix

Re: [PATCH 2/2] ath9k: Choose highest rate of MRR based on IEEE80211_TX_CTL_USE_MINRATE

[Rajkumar Manoharan]

On Thu, Sep 29, 2011 at 03:06:23PM +0200, Felix Fietkau wrote:
> On 2011-09-29 2:14 PM, Rajkumar Manoharan wrote:
> >On Thu, Sep 29, 2011 at 01:32:03PM +0200, Felix Fietkau wrote:
> >> On 2011-09-29 1:24 PM, Rajkumar Manoharan wrote:
> >> >Select appropriate rate as highest rate of rate series, if the frame
> >> >was asked to be sent at minimum rate. For example nullfunc frames
> >> >either can be sent at HT rates on normal case or at non-HT rates if
> >> >it is used for connection monitoring.
> >> >
> >> >Signed-off-by: Rajkumar Manoharan<rmanohar@qca.qualcomm.com>
> >> >---
> >> >   drivers/net/wireless/ath/ath9k/rc.c |    4 ++--
> >> >   1 files changed, 2 insertions(+), 2 deletions(-)
> >> >
> >> Shouldn't the check for IEEE80211_TX_CTL_USE_MINRATE be in
> >> rate_control_send_low(), so that it does not have to be repeated in
> >> every single rate control module?
> >>
> >But I donno what could be the side effect of changing rate_control_send_low
> >as it is used by all drivers. And also if the rate control provide the
> >minrate, it can be used to update the PER upon tx status. isnt it?
> It always updates the PER upon tx status, even if
> rate_control_send_low was used. It should work the same way for
> every driver, so I think putting this in the ath9k rc is the wrong
> place, and it would be weird if a flag with such a generic name as
> IEEE80211_TX_CTL_USE_MINRATE would be used by some rate control
> modules and ignored by others.
>
That true. Till now rate_control_send_low never be used for data frame.
So just to be causious, I dicided to process tx_ctl at rate control side.
If it wont break any rate control algo other than ath9k, then I send my
earlier rfc patch. Thanks for your input.

--
Rajkumar