[PATCH v1 1/2] ath9k: fix ath_get_rate_txpower() to respect the rate list end tag

[PATCH v1 1/2] ath9k: fix ath_get_rate_txpower() to respect the rate list end tag

[Peter Seiderer]

Stop reading (and copying) from ieee80211_tx_rate to ath_tx_info.rates
after list end tag (count == 0, idx < 0), prevents copying of garbage
to card registers.

Note: no need to write to the remaining ath_tx_info.rates entries
as the complete ath_tx_info struct is already initialized to zero from
both call sites.

Signed-off-by: Peter Seiderer <ps.report@gmx.net>
---
 drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index d0caf1de2bde..ec9bad2d9510 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1271,7 +1271,7 @@ static void ath_buf_set_rate(struct ath_softc *sc, struct ath_buf *bf,
 		int phy;
 
 		if (!rates[i].count || (rates[i].idx < 0))
-			continue;
+			break;
 
 		rix = rates[i].idx;
 		info->rates[i].Tries = rates[i].count;
-- 
2.35.1

[PATCH v1 2/2] mac80211: minstrel_ht: fill all requested rates

[Peter Seiderer]

Fill all requested rates (in case of ath9k 4 rate slots are
available, so fill all 4 instead of only 3), improves throughput in
noisy environment.

Signed-off-by: Peter Seiderer <ps.report@gmx.net>
---
 net/mac80211/rc80211_minstrel_ht.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index 9c6ace858107..cd6a0f153688 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -1436,17 +1436,17 @@ minstrel_ht_update_rates(struct minstrel_priv *mp, struct minstrel_ht_sta *mi)
 	/* Start with max_tp_rate[0] */
 	minstrel_ht_set_rate(mp, mi, rates, i++, mi->max_tp_rate[0]);
 
-	if (mp->hw->max_rates >= 3) {
-		/* At least 3 tx rates supported, use max_tp_rate[1] next */
-		minstrel_ht_set_rate(mp, mi, rates, i++, mi->max_tp_rate[1]);
-	}
+	/* Fill up remaining, keep one entry for max_probe_rate */
+	for (; i < (mp->hw->max_rates - 1); i++)
+		minstrel_ht_set_rate(mp, mi, rates, i, mi->max_tp_rate[i]);
 
-	if (mp->hw->max_rates >= 2) {
+	if (i < mp->hw->max_rates)
 		minstrel_ht_set_rate(mp, mi, rates, i++, mi->max_prob_rate);
-	}
+
+	if (i < IEEE80211_TX_RATE_TABLE_SIZE)
+		rates->rate[i].idx = -1;
 
 	mi->sta->max_rc_amsdu_len = minstrel_ht_get_max_amsdu_len(mi);
-	rates->rate[i].idx = -1;
 	rate_control_set_rates(mp->hw, mi->sta, rates);
 }
 
-- 
2.35.1

Re: [PATCH v1 1/2] ath9k: fix ath_get_rate_txpower() to respect the rate list end tag

[Toke Høiland-Jørgensen]

Peter Seiderer <ps.report@gmx.net> writes:

> Stop reading (and copying) from ieee80211_tx_rate to ath_tx_info.rates
> after list end tag (count == 0, idx < 0), prevents copying of garbage
> to card registers.

In the normal case I don't think this patch does anything, since any
invalid rate entries will already be skipped (just one at a time instead
of all at once). So this comment is a bit misleading.

Also, Minstrel could in principle produce a rate sequence where the
indexes are all positive, but there's one in the middle with a count of
0, couldn't it? With this patch, the last entries of such a sequence
would now be skipped...

-Toke

Re: [PATCH v1 2/2] mac80211: minstrel_ht: fill all requested rates

[Toke Høiland-Jørgensen]

+Felix

Peter Seiderer <ps.report@gmx.net> writes:

> Fill all requested rates (in case of ath9k 4 rate slots are
> available, so fill all 4 instead of only 3), improves throughput in
> noisy environment.

How did you test this? Could you quantify the gains in throughput you saw?

-Toke

> Signed-off-by: Peter Seiderer <ps.report@gmx.net>
> ---
>  net/mac80211/rc80211_minstrel_ht.c | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
> index 9c6ace858107..cd6a0f153688 100644
> --- a/net/mac80211/rc80211_minstrel_ht.c
> +++ b/net/mac80211/rc80211_minstrel_ht.c
> @@ -1436,17 +1436,17 @@ minstrel_ht_update_rates(struct minstrel_priv *mp, struct minstrel_ht_sta *mi)
>  	/* Start with max_tp_rate[0] */
>  	minstrel_ht_set_rate(mp, mi, rates, i++, mi->max_tp_rate[0]);
>  
> -	if (mp->hw->max_rates >= 3) {
> -		/* At least 3 tx rates supported, use max_tp_rate[1] next */
> -		minstrel_ht_set_rate(mp, mi, rates, i++, mi->max_tp_rate[1]);
> -	}
> +	/* Fill up remaining, keep one entry for max_probe_rate */
> +	for (; i < (mp->hw->max_rates - 1); i++)
> +		minstrel_ht_set_rate(mp, mi, rates, i, mi->max_tp_rate[i]);
>  
> -	if (mp->hw->max_rates >= 2) {
> +	if (i < mp->hw->max_rates)
>  		minstrel_ht_set_rate(mp, mi, rates, i++, mi->max_prob_rate);
> -	}
> +
> +	if (i < IEEE80211_TX_RATE_TABLE_SIZE)
> +		rates->rate[i].idx = -1;
>  
>  	mi->sta->max_rc_amsdu_len = minstrel_ht_get_max_amsdu_len(mi);
> -	rates->rate[i].idx = -1;
>  	rate_control_set_rates(mp->hw, mi->sta, rates);
>  }
>  
> -- 
> 2.35.1

Re: [PATCH v1 1/2] ath9k: fix ath_get_rate_txpower() to respect the rate list end tag

[Peter Seiderer]

Hello Toke,

On Mon, 04 Apr 2022 20:19:39 +0200, Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Peter Seiderer <ps.report@gmx.net> writes:
> 
> > Stop reading (and copying) from ieee80211_tx_rate to ath_tx_info.rates
> > after list end tag (count == 0, idx < 0), prevents copying of garbage
> > to card registers.  
> 
> In the normal case I don't think this patch does anything, since any
> invalid rate entries will already be skipped (just one at a time instead
> of all at once). So this comment is a bit misleading.

Save some (minimal) compute time? Found it something misleading while
debugging to see random values written out to the card and found this
comment in net/mac80211/rate.c:

 648                 /*
 649                  * make sure there's no valid rate following
 650                  * an invalid one, just in case drivers don't
 651                  * take the API seriously to stop at -1.
 652                  */

and multiple places doing the same check (count == 0, idx < 0) for validation
e.g.:

 723                 if (i < ARRAY_SIZE(info->control.rates) &&
 724                     info->control.rates[i].idx >= 0 &&
 725                     info->control.rates[i].count) {

or 

 742                 if (rates[i].idx < 0 || !rates[i].count)
 743                         break;

> 
> Also, Minstrel could in principle produce a rate sequence where the
> indexes are all positive, but there's one in the middle with a count of
> 0, couldn't it? With this patch, the last entries of such a sequence
> would now be skipped...

According to net/mac80211/rc80211_minstrel_ht.c:

1128 static bool
1129 minstrel_ht_txstat_valid(struct minstrel_priv *mp, struct minstrel_ht_sta *     mi,
1130                          struct ieee80211_tx_rate *rate)
1131 {
1132         int i;
1133 
1134         if (rate->idx < 0)
1135                 return false;
1136 
1137         if (!rate->count)
1138                 return false;
1139 

minstrel although evaluates a rate count of zero as invalid...

Regards,
Peter

> 
> -Toke

Re: [PATCH v1 2/2] mac80211: minstrel_ht: fill all requested rates

[Peter Seiderer]

Hello Toke, Felix,

On Mon, 04 Apr 2022 20:21:24 +0200, Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> +Felix
> 
> Peter Seiderer <ps.report@gmx.net> writes:
> 
> > Fill all requested rates (in case of ath9k 4 rate slots are
> > available, so fill all 4 instead of only 3), improves throughput in
> > noisy environment.  
> 
> How did you test this? Could you quantify the gains in throughput you saw?

Investigating some performance degradation of a wifi system original with ath5k
cards using a legacy kernel and madwifi driver compared against the 
performance using a ath9k card running IBSS mode over long distance/with
additional amplifier and using iperf for measurement...

With the ath5k cards under bad conditions the throughput is going down below
10 Mbits/s but with stable throughput..., with the ath9k card and the exact same
setup there are short periods with good throughput values and periods up to 10-15
seconds with 0 Mbits/s...

The actual in-door/laboratory test setup is a wired connection between the
two wifi systems (with fixed attenuators in between) and an adjustable noise/
disturb signal induced by a signal generator...

Without this patch the 0 Mbits/s periods from the field test are reproducible,
with this patch applied we see a more or less stable throughput of 1-5 Mbits/s...

Regards,
Peter

> 
> -Toke
> 
> > Signed-off-by: Peter Seiderer <ps.report@gmx.net>
> > ---
> >  net/mac80211/rc80211_minstrel_ht.c | 14 +++++++-------
> >  1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
> > index 9c6ace858107..cd6a0f153688 100644
> > --- a/net/mac80211/rc80211_minstrel_ht.c
> > +++ b/net/mac80211/rc80211_minstrel_ht.c
> > @@ -1436,17 +1436,17 @@ minstrel_ht_update_rates(struct minstrel_priv *mp, struct minstrel_ht_sta *mi)
> >  	/* Start with max_tp_rate[0] */
> >  	minstrel_ht_set_rate(mp, mi, rates, i++, mi->max_tp_rate[0]);
> >  
> > -	if (mp->hw->max_rates >= 3) {
> > -		/* At least 3 tx rates supported, use max_tp_rate[1] next */
> > -		minstrel_ht_set_rate(mp, mi, rates, i++, mi->max_tp_rate[1]);
> > -	}
> > +	/* Fill up remaining, keep one entry for max_probe_rate */
> > +	for (; i < (mp->hw->max_rates - 1); i++)
> > +		minstrel_ht_set_rate(mp, mi, rates, i, mi->max_tp_rate[i]);
> >  
> > -	if (mp->hw->max_rates >= 2) {
> > +	if (i < mp->hw->max_rates)
> >  		minstrel_ht_set_rate(mp, mi, rates, i++, mi->max_prob_rate);
> > -	}
> > +
> > +	if (i < IEEE80211_TX_RATE_TABLE_SIZE)
> > +		rates->rate[i].idx = -1;
> >  
> >  	mi->sta->max_rc_amsdu_len = minstrel_ht_get_max_amsdu_len(mi);
> > -	rates->rate[i].idx = -1;
> >  	rate_control_set_rates(mp->hw, mi->sta, rates);
> >  }
> >  
> > -- 
> > 2.35.1  

Re: [PATCH v1 1/2] ath9k: fix ath_get_rate_txpower() to respect the rate list end tag

[Toke Høiland-Jørgensen]

Peter Seiderer <ps.report@gmx.net> writes:

> Hello Toke,
>
> On Mon, 04 Apr 2022 20:19:39 +0200, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
>> Peter Seiderer <ps.report@gmx.net> writes:
>> 
>> > Stop reading (and copying) from ieee80211_tx_rate to ath_tx_info.rates
>> > after list end tag (count == 0, idx < 0), prevents copying of garbage
>> > to card registers.  
>> 
>> In the normal case I don't think this patch does anything, since any
>> invalid rate entries will already be skipped (just one at a time instead
>> of all at once). So this comment is a bit misleading.
>
> Save some (minimal) compute time? Found it something misleading while
> debugging to see random values written out to the card and found this
> comment in net/mac80211/rate.c:
>
>  648                 /*
>  649                  * make sure there's no valid rate following
>  650                  * an invalid one, just in case drivers don't
>  651                  * take the API seriously to stop at -1.
>  652                  */
>
> and multiple places doing the same check (count == 0, idx < 0) for validation
> e.g.:
>
>  723                 if (i < ARRAY_SIZE(info->control.rates) &&
>  724                     info->control.rates[i].idx >= 0 &&
>  725                     info->control.rates[i].count) {
>
> or 
>
>  742                 if (rates[i].idx < 0 || !rates[i].count)
>  743                         break;
>
>> 
>> Also, Minstrel could in principle produce a rate sequence where the
>> indexes are all positive, but there's one in the middle with a count of
>> 0, couldn't it? With this patch, the last entries of such a sequence
>> would now be skipped...
>
> According to net/mac80211/rc80211_minstrel_ht.c:
>
> 1128 static bool
> 1129 minstrel_ht_txstat_valid(struct minstrel_priv *mp, struct minstrel_ht_sta *     mi,
> 1130                          struct ieee80211_tx_rate *rate)
> 1131 {
> 1132         int i;
> 1133 
> 1134         if (rate->idx < 0)
> 1135                 return false;
> 1136 
> 1137         if (!rate->count)
> 1138                 return false;
> 1139 
>
> minstrel although evaluates a rate count of zero as invalid...

So my concern was mostly that the documentation (in mac80211.h) says
that an idx of -1 indicates the end, but says nothing about the count.
Which implies that in principle you could have a rate table of { idx,
count } like { 1, 1 }, { 2, 0 }, { 3, 1 } which would mean all three
rates was valid but the second one would just be "skipped" due to a
count of zero.

But it seems that the code populating the rate table that you linked
above (lines 742/743) actually do abort on either condition, so I guess
it's safe to do so in the driver as well...

-Toke

Re: [PATCH v1 1/2] ath9k: fix ath_get_rate_txpower() to respect the rate list end tag

[Toke Høiland-Jørgensen]

Peter Seiderer <ps.report@gmx.net> writes:

> Stop reading (and copying) from ieee80211_tx_rate to ath_tx_info.rates
> after list end tag (count == 0, idx < 0), prevents copying of garbage
> to card registers.
>
> Note: no need to write to the remaining ath_tx_info.rates entries
> as the complete ath_tx_info struct is already initialized to zero from
> both call sites.
>
> Signed-off-by: Peter Seiderer <ps.report@gmx.net>

Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>

Re: [PATCH v1 1/2] ath9k: fix ath_get_rate_txpower() to respect the rate list end tag

[Kalle Valo]

Peter Seiderer <ps.report@gmx.net> wrote:

> Stop reading (and copying) from ieee80211_tx_rate to ath_tx_info.rates
> after list end tag (count == 0, idx < 0), prevents copying of garbage
> to card registers.
> 
> Note: no need to write to the remaining ath_tx_info.rates entries
> as the complete ath_tx_info struct is already initialized to zero from
> both call sites.
> 
> Signed-off-by: Peter Seiderer <ps.report@gmx.net>
> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>

Patch applied to ath-next branch of ath.git, thanks.

24584d4f0afc ath9k: fix ath_get_rate_txpower() to respect the rate list end tag

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20220402153014.31332-1-ps.report@gmx.net/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches