>> > > But that notification trap would also have to call some function >> > > in the stack, and the drivers that don't have it (or don't >> > > implement it yet) need something more like this patch? >> > >> > (see v3 attached to this mail). >> > >> > Yes, drivers that don't pass BAs to the stack and won't call >> > ieee80211_ba_notification will have their BA sessions "removed" in v3. >> > Of course, we can also retain the old behavoir and reset the >> > tx ba session timeout until we know we don't break anything. >> >> But if the peer acked a packet sent in a BA session, then it must send >> a BA (spec AFAIK), so when the driver calls ieee80211_tx_status at the >> originator side, mac80211 can assume that a BA was received, right? > Not necessarily, some wifi devices (especially USB) just don't provide > a status report. I think rtlwifi is a example for this case, since it > just sticks "STAT_ACK" on every package. > > (Also, when the signal is bad, some devices fall back to legacy (retry) > rates and abandon aggregation at least for the time... so no, we > have to look elsewhere. Furthermore, I haven't found any > references in the spec that explicitly says that you can't > do that (e.g. A-MSDU vs A-MPDU mixed, etc...), so do you know > the paragraph that says BAs and normal acks can't be mixed?) Frankly I am not an expert at browsing the spec :-) I just know that Cisco sends BA all the time, but it is Cisco and I don't remember what other APs do. >> Even if you still want a specific notification from the driver to >> mac80211, what about adding it to ieee80211_tx_info.status ? >> We have a trade-off here. We can have a new notification which is a >> new API (which is a disadvantage in terms of runtime and design) but >> can be called once per batch: meaning that we will reset the the timer >> once every 15 packets or so. Or we can have a bit in the >> ieee80211_tx_info.status which would be in every packet, but then, no >> need for new API. >> Maybe the best way is to have the driver set the new bit in >> ieee80211_tx_info.status only for the last packet of the batch (or the >> first, whatever). > If you look in ieee80211_tx_prep_agg you'll see that in the current > design the timer is already updated for every frame as well. So if > we just move this to a different place so the "cost" should remain > the same, right? > That sounds right -- 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
