Hi Felix, Sorry to use your time again... > But much more important than that is to not cause regressions for other > people via aggressive packet dropping. Agreed, but see below. > If you put the code in minstrel (and minstrel_ht), it not only allows > making a better tradeoff for retry handling, the code also doesn't have > to be run for every single packet. You can run it during the rate > control stats update. OK, I'll have a look at that part now. > > The reduction of retry attempts definitely needs to be balanced > properly. Retries with max_prob_rate can be more important than retries > with max_tp_rate, but there needs to be a minimum for each of those. This leads to a question about regressions and backward compatibility: Since minstrel can compute as much as 28 retries for a frame, And since the (standard) default value for "short_frame_max_tx_count" is 7, ... there is no way I can enforce the configured value while keeping minstrel counts by default ! The standard itself gives a very aggressive limit! Or am I mistaken about the significance of this configuration parameter ? Jean-Pierre -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
