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:
adrian 2012-03-09 22:58:34 +00:00
parent fe40fdbb98
commit 5ccebb7a33

View File

@ -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;