> Johannes Berg <johannes@xxxxxxxxxxxxxxxx> schrieb:
> >On Wed, 2014-01-22 at 20:16 +0100, Karl Beldan wrote:
> >
> >> > Given the fact that we only send the frame from
> >> > ieee80211_stop_tx_ba_cb() I don't see any problem. Even if we were
> >to
> >> > send the frame directly after calling the ampdu_action, it seems it
> >> > would be fine, since the callback (now) requires sending the
> >remaining
> >> > frames unaggregated. (Given that, I'm not even sure why we required
> >the
> >> > packets to be sent unaggregated, Emmanuel, do you remember?)
> >> >
> >> I'd expect most device to not block ack such frames, and they'd be
> >> right to do so, sending them unaggregated seems the right thing to
> >do.
> >
> >Oh, I roughly remember now - we didn't want to separate the cases of us
> >sending a delBA and us receiving a delBA. If we receive a delBA, we
> >should stop sending aggregated frames immediately (actually for iwlwifi
> >the firmware will do that) or as quickly as possible, hence the
> >requirement
> >
> >If we decide to tear down the session ourselves then we could continue
> >sending until later, but it's not worth it.
> >
Exactly - we wanted to unify the initiator (the TXing side decides to stop the BA agreement) and the recipient (the RXing side decides to stop the BA agreement) cases. So it goes like this:
If you get are TXing and you get a (recipient) DELBA, then you need to stop sending AMPDUs straight away. This is why Intel cards have the firmware do this. But since iwlwifi uses different queues for non-aggregated traffic and AMPDUs, we must wait until all the packets in the AMPDU queue will drain, and only then, allow mac80211 to send packets to the non-aggregated traffic queue. Now - even vendors that don't prevent the AMPDUs in firmware should still do the same (provided that they use different queues for AMPDU and non-AMPDU traffic). This is not to prevent sending AMPDUs after DELBA, but more to prevent out-of-order TX.
In the case of originator DELBA, it is slightly different. We can choose when to send the DELBA after all. Of course we still have the out-of-order thing to take care about, but at least, we can avoid the "AMPDUs after DELBA" even without firmware support.
The only thing you have to do is to make sure that ieee80211_stop_tx_ba_cb is called only *after* the driver is sure that all the packets in the AMPDU queue are sent. Mac80211 won't send the DELBA before the low level driver calls ieee80211_stop_tx_ba_cb. So, if the driver is able to tell mac80211 when it is finished with the AMPDU packets, you can safely send it in VO and not fear any "AMPDU after DELBA" problem.
Another (side) point. Even if you can stop sending AMPDUs straight away (iwlwifi can do that with a command to the firmware that will be much faster than waiting for queues to drain), you still have the Tx out-of-order problem.
So that technically, we could have a more fine grain resolution in mac80211 that allows the low level driver to have mac80211 send the DELBA earlier, but still prevents mac80211 from sending packets to the low level driver until the all the queues are drained.
But this is definitely not worth the complexity since delaying the DELBA by a bit doesn't cost anything.
Hope that helps :)
> >> So, I guess you are taking what I sent ?
> >
> >Haven't really made up my mind yet ... I think it's more correct, so I
> >should, but I also don't really want to break the ralink drivers over
> >what seems to me to be a fairly small issue.
>
> I think I'm fine with this now. Let's just see if someone experiences any
> issues ...
>
> Furthermore I think i even remember that you can force ralink HW to stop a
> BA session. But all in all lets better comply with the spec ...
Well - you need to see what "stop a BA session" mean. If you are able to tell the HW no AMPDUs anymore *now*, then ok - but you still have the out-of-order TX problem. Unless you use the same TX queue for AMPUs and non-AMPDUs and don't fear reordering issues
>
> Helmut
��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
