On 2013-07-02 7:40 PM, Jean-Pierre Tosoni wrote: > 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 ? I think you're right about this. Specifically because the standard limit is much lower than what is being used now, we need to really make sure that it's applied in a way that it does not harm the normal use case in any visible way. - Felix -- 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
