minstrel_ht: fill out more than 3 rates

Hello Felix,

I've stumbled into this conundrum a while ago... then as usual: forgot that it existed, until yesterday:

As you know minstrel (our non ht fallback) enables mrr-mode only if the driver sets hw->max_rates to 4 or more. minstrel_ht - on the other hand - just prepares a set of 3 rates, so at least one additional retry with different tx-vectors remains unused...

How the last tries should be used is up for debate, I've opted out for lowest possible MCS. (although, some devices may also use a legacy
rate for the final tries...)

And the reason why I think it's worth to do an additional
round: The reordering penalty for lost MPDUs on the receiver- side can be as high as 100ms, which is quite expensive compared to some extra airtime...
---

index c5b4659..5f44c0b 100644
@@ -584,7 +584,7 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
 	struct minstrel_ht_sta_priv *msp = priv_sta;
 	struct minstrel_ht_sta *mi = &msp->ht;
 	struct minstrel_priv *mp = priv;
-	int sample_idx;
+	int sample_idx, i = 0;
 
 	if (rate_control_send_low(sta, priv_sta, txrc))
 		return;

@@ -595,21 +595,29 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
 	info->flags |= mi->tx_flags;
 	sample_idx = minstrel_get_sample_rate(mp, mi);
 	if (sample_idx >= 0) {
-		minstrel_ht_set_rate(mp, mi, &ar[0], sample_idx,
+		minstrel_ht_set_rate(mp, mi, &ar[i++], sample_idx,
 			txrc, true, false);
-		minstrel_ht_set_rate(mp, mi, &ar[1], mi->max_tp_rate,
+		minstrel_ht_set_rate(mp, mi, &ar[i++], mi->max_tp_rate,
 			txrc, false, true);
 		info->flags |= IEEE80211_TX_CTL_RATE_CTRL_PROBE;
 	} else {
-		minstrel_ht_set_rate(mp, mi, &ar[0], mi->max_tp_rate,
+		minstrel_ht_set_rate(mp, mi, &ar[i++], mi->max_tp_rate,
 			txrc, false, false);
-		minstrel_ht_set_rate(mp, mi, &ar[1], mi->max_tp_rate2,
+		minstrel_ht_set_rate(mp, mi, &ar[i++], mi->max_tp_rate2,
 			txrc, false, true);
 	}
-	minstrel_ht_set_rate(mp, mi, &ar[2], mi->max_prob_rate, txrc, false, true);
+	minstrel_ht_set_rate(mp, mi, &ar[i++], mi->max_prob_rate,
+			     txrc, false, true);
 
-	ar[3].count = 0;
-	ar[3].idx = -1;
+	for (;i < mp->hw->max_rates; i++) {
+		minstrel_ht_set_rate(mp, mi, &ar[i++], 0,
+				     txrc, false, true);
+	}
+
+	for (; i < IEEE80211_TX_MAX_RATES; i++) {
+		ar[i].count = 0;
+		ar[i].idx = -1;
+	}
 
 	mi->total_packets++;
 

The problem here is that we have very different forms of retransmission that receive the same kind of tx rate information, even though they should be treated in a different way.

With drivers like ath9k, we don't need many retransmission steps. The hardware-level retransmission stops as soon as it receives a Block Ack, even if that may only ACK one of many frames (or maybe even none at all). Software retransmission is then used to ensure that we don't usually see lost MPDUs (under sane conditions, software-level excessive retries should be pretty rare).

With this form of aggregation, the processing of the MRR chain is always restarted for the next transmission attempt.
Since the table is for hw-level retransmission only, we do need to ensure that we don't put unnecessarily low rates into the MRR array, as this will limit aggregation size based on the 4-ms limit.

When using hardware aggregation, the behaviour kind of depends on how the hardware interprets the retransmission information and how many times it retransmits failed subframes of an A-MPDU transmission that received a Block Ack.

I think in the long run we need to split this up. In my software aggregation rewrite, I plan to add rate control lookups per A-MPDU, so that the rate control algorithm can make a decision based on the number of failed subframes (or the delta between first frame seqno and last frame seqno, to better utilize the block ack window). In this case, the rate control can be (and should be) much more optimistic about rates, whereas with hardware aggregation we should probably put more emphasis on reliability to reduce the latency.

- Felix