Skip to contentSkip to conversation

ath9k: improve max rate retry handling

PATCH In review Felix Fietkau 3 participants 3 messages Jan 24, 2010 – Jan 27, 2010 Qualcomm Atheros ATH9K wireless driver

lore
Share & tools
lore

Felix Fietkau

author
#0 lore raw

PATCH 1/1 ath9k: improve max rate retry handling

ath9k currently forces hw->max_rate_tries to 4 to work around rate control inefficiencies. This has some negative side effects, such as rate_control_send_low also using a maximum of 4 tries, which could negatively affect reliability of unicast management frames. This patch pushes the retry limit to the rate control instead, and allows it to use more tries on the last stage to prevent unnecessary packet loss.

Signed-off-by Felix Fietkau <[email protected]>

---

drivers/net/wireless/ath/ath9k/init.c +1 -2
@@ -645,8 +645,7 @@ void ath9k_set_hw_capab(struct ath_softc
 	hw->max_rates = 4;
 	hw->channel_change_time = 5000;
 	hw->max_listen_interval = 10;
-	/* Hardware supports 10 but we use 4 */
-	hw->max_rate_tries = 4;
+	hw->max_rate_tries = 10;
 	hw->sta_data_size = sizeof(struct ath_node);
 	hw->vif_data_size = sizeof(struct ath_vif);
drivers/net/wireless/ath/ath9k/rc.c +6 -6
@@ -678,13 +678,13 @@ static void ath_get_rate(void *priv, str
 	 * For Multi Rate Retry we use a different number of
 	 * retry attempt counts. This ends up looking like this:
 	 *
-	 * MRR[0] = 2
-	 * MRR[1] = 2
-	 * MRR[2] = 2
-	 * MRR[3] = 4
+	 * MRR[0] = 4
+	 * MRR[1] = 4
+	 * MRR[2] = 4
+	 * MRR[3] = 8
 	 *
 	 */
-	try_per_rate = sc->hw->max_rate_tries;
+	try_per_rate = 4;
 
 	rate_table = sc->cur_rate_table;
 	rix = ath_rc_get_highest_rix(sc, ath_rc_priv, rate_table, &is_probe);

@@ -714,7 +714,7 @@ static void ath_get_rate(void *priv, str
 	for ( ; i < 4; i++) {
 		/* Use twice the number of tries for the last MRR segment. */
 		if (i + 1 == 4)
-			try_per_rate = 4;
+			try_per_rate = 8;
 
 		ath_rc_get_lower_rix(rate_table, ath_rc_priv, rix, &nrix);
 		/* All other rates in the series have RTS enabled */
#1 lore raw
Quoted 7 lines · Felix Fietkau

ath9k currently forces hw->max_rate_tries to 4 to work around rate control inefficiencies. This has some negative side effects, such as rate_control_send_low also using a maximum of 4 tries, which could negatively affect reliability of unicast management frames. This patch pushes the retry limit to the rate control instead, and allows it to use more tries on the last stage to prevent unnecessary packet loss.

If this is not merged yet and if its not too much trouble, would you mind splitting this into two separate patches, one which increases the MRR segment retry count, and the other which does what the current commit log says? Reason is increasing the MRR segment retry count might be useful as a cherry pick for older kernels.

Luis

#2 lore raw
Quoted 9 lines · Luis R. Rodriguez
Quoted 7 lines · Felix Fietkau

ath9k currently forces hw->max_rate_tries to 4 to work around rate control inefficiencies. This has some negative side effects, such as rate_control_send_low also using a maximum of 4 tries, which could negatively affect reliability of unicast management frames. This patch pushes the retry limit to the rate control instead, and allows it to use more tries on the last stage to prevent unnecessary packet loss.

Quoted 5 lines

If this is not merged yet and if its not too much trouble, would you mind splitting this into two separate patches, one which increases the MRR segment retry count, and the other which does what the current commit log says? Reason is increasing the MRR segment retry count might be useful as a cherry pick for older kernels.

It's already merged...

Signature · 2 lines
John W. Linville		Someday the world will need a hero, and you
[email protected]			might be all we have.  Be ready.