On Wed, Jan 22, 2014 at 4:28 PM, Karl Beldan <karl.beldan@xxxxxxxxx> wrote:
> On Wed, Jan 22, 2014 at 02:33:14PM +0100, Helmut Schaa wrote:
>> On Wed, Jan 22, 2014 at 2:09 PM, Karl Beldan <karl.beldan@xxxxxxxxx> wrote:
>> > On Wed, Jan 22, 2014 at 01:34:39PM +0100, Johannes Berg wrote:
>> >> Hmm. I guess you're right about the spec, but I vaguely remember races
>> >> in this with the delBA going out too soon or so?
>> >>
>> >
>> > Indeed, this was intended by cf6bb79 ("Use appropriate TID for sending
>> > BAR, ADDBA and DELBA frames") and I overlooked it .. will look into it,
>> > thanks.
>> > I Cced Helmut who authored the said commit.
>>
>> You're right. There were some issues with that, but that was 2 years ago :)
>>
>> Sending ADDBA over AV_VO should be safe.
>> If a DELBA is sent as AC_VO it might get received before the last AMPDU
>> of the BlockAck session. So, the pending AMPDUs will get dropped at the
>> receiver.
>>
>> In theory this could also be avoided by properly flushing all pending AMPDUs
>> of the TID in question from the hw queues or by waiting for the tx status
>> of all pending AMPDUs.
>>
>
> I just looked at the code with your change in mind and couldn't find any
> issue caused by sending {add,del}ba on AC_VO.
> As of today, a delba is sent only after a driver has called 'purposely'
> ieee80211_stop_tx_ba_cb_irqsafe so I see no issue with the delba either,
> do you see one today ?
If the driver does the right thing by flushing the right frames in the
hw tx queues
I think this should be ok. At least rt2x00 is not doing that, but
maybe that's just
an issue in rt2x00 :(
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
