Re: [RFC PATCH 1/2] mac80211: Retry null data frame for power save.

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

On Thu, 2010-02-04 at 12:24 +0530, Vivek Natarajan wrote:

> @@ -275,6 +274,18 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
>  			local->dot11FailedCount++;
>  	}
>  
> +	if (ieee80211_is_nullfunc(fc) && ieee80211_has_pm(fc) &&
> +			(local->hw.conf.flags & IEEE80211_CONF_PS)) {
> +		if (!(info->flags & IEEE80211_TX_STAT_ACK)) {
> +			ieee80211_stop_queues_by_reason(&local->hw,
> +					IEEE80211_QUEUE_STOP_REASON_PS);
> +			ieee80211_queue_work(&local->hw,
> +					&local->dynamic_ps_disable_work);
> +			mod_timer(&local->dynamic_ps_timer, jiffies +
> +					msecs_to_jiffies(10));
> +		}
> +	}
> +

This will still lose packets in the time between frame tx and status
report. And in fact, it'll also lose packets from lower-priority queues,
since ath9k doesn't implement flushing yet. It really should :)

On the other hand, there is hardware (even from Atheros/Zydas!) that
will not provide status reports for every frame.

Also, I'm not entirely sure why the AP would lose the frame? It's a
unicast frame that will be retransmitted quite a number of times. Is it
really actually going out on the air or is there something else wrong?
Maybe just the queue priority inversion issue since this frame goes out
as higher priority as most data frames?

If you really need to provide this functionality I think you should
probably do it "properly" in the sense that you react to the "frame
acked" by enabling PS, rather than the other way around. That requires a
hardware flag though that enables mac80211 to know that all frames will
get a status report unless something is seriously wrong, since otherwise
we'd *never* go into PS.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]