Document that we may end up with some suboptimal handling of data
frames with stations in power saving mode. I'm not (yet) sure how to handle TX'ing aggregates frames to stations that are in power saving mode, or whether that's even a feasible thing to do. So in order to (mostly) not forget, leave a couple of comments in the code. The code presently assumes that the aggregation TID state for an ath_node is locked not by the ath_node lock or a node+TID lock, but behind the hardware queue said TID maps to. This assumption is going to be incorrect for stations in power saving mode as we'll be TX'ing frames on the multicast queue. In any case, I'm afraid its a "later problem". :/
This commit is contained in:
parent
fe40fdbb98
commit
5ccebb7a33
@ -1162,6 +1162,11 @@ ath_tx_normal_setup(struct ath_softc *sc, struct ieee80211_node *ni,
|
||||
* (or) if there is some mcast data waiting on the mcast
|
||||
* queue (to prevent out of order delivery) multicast
|
||||
* frames must be buffered until after the beacon.
|
||||
*
|
||||
* XXX This likely means that if there's a station in power
|
||||
* save mode, we won't be doing any kind of aggregation towards
|
||||
* anyone. This is likely a very suboptimal way of dealing
|
||||
* with things.
|
||||
*/
|
||||
if (ismcast && (vap->iv_ps_sta || avp->av_mcastq.axq_depth))
|
||||
txq = &avp->av_mcastq;
|
||||
@ -1409,6 +1414,12 @@ ath_tx_start(struct ath_softc *sc, struct ieee80211_node *ni,
|
||||
if (ismcast)
|
||||
txq = &avp->av_mcastq;
|
||||
|
||||
/*
|
||||
* XXX This likely means that if there's a station in power
|
||||
* save mode, we won't be doing any kind of aggregation towards
|
||||
* anyone. This is likely a very suboptimal way of dealing
|
||||
* with things.
|
||||
*/
|
||||
if ((! is_ampdu) && (vap->iv_ps_sta || avp->av_mcastq.axq_depth))
|
||||
txq = &avp->av_mcastq;
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user