Hi.
Thanks for your comments!
2011/11/29 Johannes Berg <johannes@xxxxxxxxxxxxxxxx>:
> On Mon, 2011-11-28 at 21:27 -0500, Nikolay Martynov wrote:
>> Currently code allows three (HT_AGG_MAX_RETRIES) unanswered addba
>> requests. When this limit is reached aggregation is turned off for
>> given TID permanently. This doesn't seem right: three requests is
>> not that much, some 'blackout' can happen, but effect of it affects
>> whole connection indefinitely.
>> This patch adds a period of time (1 minute) after which counter of
>> sent addba requests is reset so addba requests can be sent again.
>> The traffic impact should be negligible, but connection will be more
>> stable.
>
> Conceptually, this seems OK to me, although on broken APs it might mean
> connection stalls every minute, not sure how desirable that is?
Do APs broken is such way exist? I.e. APs which declare aggregation
support but do not respond to addba.
On the other hand looking at the code I've got an impression that
connection doesn't stall while waiting for addba resp, i.e. packets
still go though non-agg path. Did I miss something in this regards?
>
>> - /* we have tried too many times, receiver does not want A-MPDU */
>> if (sta->ampdu_mlme.addba_req_num[tid] > HT_AGG_MAX_RETRIES) {
>> - ret = -EBUSY;
>> - goto err_unlock_sta;
>> + unsigned int timestamp = jiffies_to_msecs(jiffies);
>> + if (timestamp - sta->ampdu_mlme.last_addba_req_time[tid] >
>> + HT_AGG_RETRIES_PERIOD) {
>
> this logic is confusing -- why ms? jiffies should be absolutely OK for
> minute-long timeouts.
Sure, I'll change this to use jiffies.
Thanks.
--
Truthfully yours,
Martynov Nikolay.
Email: mar.kolya@xxxxxxxxx
--
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
