On Tue, Feb 14, 2012 at 11:59 AM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> wrote:
> On Mon, 2012-02-06 at 16:48 +0100, Helmut Schaa wrote:
>> Hi,
>>
>> since all action frames are handled in the iface workqueue the following
>> situation can cause problems on slow devices in AP mode:
>>
>> - data stream AP -> STA with established TX BA session
>> - peer sends a DELBA to tear the APs TX BA session down
>> - new frames are still send as AMPDU but the receiver doesn't BlockAck
>> them anymore since it assumes the BA session is already teared down.
>> - DELBA gets processed
>
>> Hence, most frames between receiving the DELBA and actually processing
>> it are basically lost. This can easily make TCP streams getting stuck for a
>> few seconds :(
>
> Why are they lost? They haven't been acknowledged so wouldn't they be
> retransmitted?
Yes, they are retried till the retransmit timeout is reached, but they
are retried
as AMPDU again (rt2x00 does this in hw).
> In any case, it seems the easiest solution may be to stop queues?
Not sure, the action frame processing in the workqueue was added
last year in this patch:
commit bed7ee6e44cb7633a4f9821688a6c7ae977615ed
Author: Johannes Berg <johannes.berg@xxxxxxxxx>
Date: Thu Jun 10 10:21:35 2010 +0200
mac80211: always process blockack action from workqueue
To prepare for making the ampdu_action callback
sleep, make mac80211 always process blockack
action frames from the skb queue. This gets rid
of the current special case for managed mode
interfaces as well.
Before that it was directly processed in the rx path.
> But to
> really make this fool-proof you'd also have to tell the driver to
> release all its internal buffers -- and you're never going to solve the
> race completely.
Correct, we will always have a small race here but getting it as small
as possible
seems reasonable to me :)
Maybe we could at least set HT_AGG_STATE_STOPPING already in the rx
path such that the aggregation logic won't continue sending AMPDUs
to the driver and instead buffers them till the work queue is processed ...
Helmut
--
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
