[RFC PATCH v2 0/2] mac80211: ps-poll implementation

[RFC PATCH v2 0/2] mac80211: ps-poll implementation

[Kalle Valo]

Here's my suggestion for how to implement ps-poll in mac80211. Also
this fixes power save again for p54/stlc45xx, but most probably breaks
ath9k. I would like to hear opinions from others, especially from
Atheros. How does ath9k cope with the ps-poll method? Also I highly
recommend to get hardware waking up for multicast frames, it would be
a lot easier and reliable that way.

Open question is that should power save be disabled whenever mac80211
is ps-polling the frames. For example, p54/stlc45xx does not require to
disable power save in that case, it just stays awake long enough to
receive the data frame from the AP. So I did not disable power save
mode in this case, but I would like to hear comments what other
hardware needs.

v2:

o RX_CONTINUE after sending ps-poll frame in ieee80211_rx_h_check_more_data()
o remove debug printk

---

Kalle Valo (2):
      mac80211: use ps-poll to request frames in power save mode
      mac80211: remove multicast check from check_tim()


 net/mac80211/ieee80211_i.h |    3 +++
 net/mac80211/mlme.c        |   51 +++++++++++++++++++++++++++++++++++---------
 net/mac80211/rx.c          |   34 +++++++++++++++++++++++++++++
 3 files changed, 78 insertions(+), 10 deletions(-)

[RFC PATCH v2 1/2] mac80211: remove multicast check from check_tim()

[Kalle Valo]

Currently mac80211 checks for the multicast tim bit from beacons and
disables power save if the bit is set. This was added to support
ath9k. But this is a bit controversial because the AP will send
multicast frames immediately after the beacon and the time constraints
are really high. Relying mac80211 to be fast enough here might not be
reliable in all situations.

Also with current implementation mac80211 disables power save whenever
multicast bit is set but it's never enabled again. So if dynamic power
save is disabled (iwconfig wlan0 power timeout 0), the power save mode
is enabled only until first multicast/broadcast frame is received, which
isn't a long time in a normal network.

The current implementation is not usable on p54/stlc45xx and the
easiest way to fix this is to remove the multicast tim bit check
altogether. Handling multicast tim bit in host is rare, most of the
designs do this in firmware/hardware, so it's better not to have it in
mac80211. It's a lot better to do this in firmware/hardware, or if
that's not possible it could be done in the driver.

Also renamed the function to ieee80211_check_tim() to follow the style
of the file.

Signed-off-by: Kalle Valo <kalle.valo@iki.fi>
---

 net/mac80211/mlme.c |   11 ++++-------
 1 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 51f021f..c7e61e2 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -575,7 +575,7 @@ static void ieee80211_sta_wmm_params(struct ieee80211_local *local,
 	}
 }
 
-static bool check_tim(struct ieee802_11_elems *elems, u16 aid, bool *is_mc)
+static bool ieee80211_check_tim(struct ieee802_11_elems *elems, u16 aid)
 {
 	u8 mask;
 	u8 index, indexn1, indexn2;
@@ -585,9 +585,6 @@ static bool check_tim(struct ieee802_11_elems *elems, u16 aid, bool *is_mc)
 	index = aid / 8;
 	mask  = 1 << (aid & 7);
 
-	if (tim->bitmap_ctrl & 0x01)
-		*is_mc = true;
-
 	indexn1 = tim->bitmap_ctrl & 0xfe;
 	indexn2 = elems->tim_len + indexn1 - 4;
 
@@ -1788,7 +1785,7 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
 	struct ieee802_11_elems elems;
 	struct ieee80211_local *local = sdata->local;
 	u32 changed = 0;
-	bool erp_valid, directed_tim, is_mc = false;
+	bool erp_valid, directed_tim;
 	u8 erp_value = 0;
 
 	/* Process beacon from the current BSS */
@@ -1816,9 +1813,9 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
 
 	if (local->hw.flags & IEEE80211_HW_PS_NULLFUNC_STACK &&
 	    local->hw.conf.flags & IEEE80211_CONF_PS) {
-		directed_tim = check_tim(&elems, ifsta->aid, &is_mc);
+		directed_tim = ieee80211_check_tim(&elems, ifsta->aid);
 
-		if (directed_tim || is_mc) {
+		if (directed_tim) {
 			local->hw.conf.flags &= ~IEEE80211_CONF_PS;
 			ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_PS);
 			ieee80211_send_nullfunc(local, sdata, 0);

[RFC PATCH v2 2/2] mac80211: use ps-poll to request frames in power save mode

[Kalle Valo]

When a directed tim bit is set, mac80211 currently disables power save
ands sends a null frame to the AP. But if dynamic power save is
disabled, mac80211 will not enable power save again. Fix this by
adding ps-poll functionality to mac80211. When a directed tim bit is
set, mac80211 sends a ps-poll frame to the AP and checks for the more
data bit in the returned data frames. Power save mode is not disabled
during ps-polling, the assumption is that firmware still receives
responses to the ps-poll frame.

Using ps-poll is slower than waking up with null frame, but I
recommend using dynamic power save in cases where throughput is
important. User space can enable it with 'iwconfig wlan0 power timeout
<value>'.

Signed-off-by: Kalle Valo <kalle.valo@iki.fi>
---

 net/mac80211/ieee80211_i.h |    3 +++
 net/mac80211/mlme.c        |   40 +++++++++++++++++++++++++++++++++++++---
 net/mac80211/rx.c          |   34 ++++++++++++++++++++++++++++++++++
 3 files changed, 74 insertions(+), 3 deletions(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c9ffadb..76814e9 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -710,6 +710,7 @@ struct ieee80211_local {
 	unsigned int wmm_acm; /* bit field of ACM bits (BIT(802.1D tag)) */
 
 	bool powersave;
+	bool pspolling;
 	struct work_struct dynamic_ps_enable_work;
 	struct work_struct dynamic_ps_disable_work;
 	struct timer_list dynamic_ps_timer;
@@ -902,6 +903,8 @@ u64 ieee80211_sta_get_rates(struct ieee80211_local *local,
 			    enum ieee80211_band band);
 void ieee80211_send_probe_req(struct ieee80211_sub_if_data *sdata, u8 *dst,
 			      u8 *ssid, size_t ssid_len);
+void ieee80211_send_pspoll(struct ieee80211_local *local,
+			   struct ieee80211_sub_if_data *sdata);
 
 /* scan/BSS handling */
 int ieee80211_request_scan(struct ieee80211_sub_if_data *sdata,
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index c7e61e2..c8778f3 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -475,6 +475,41 @@ static void ieee80211_send_deauth_disassoc(struct ieee80211_sub_if_data *sdata,
 	ieee80211_tx_skb(sdata, skb, ifsta->flags & IEEE80211_STA_MFP_ENABLED);
 }
 
+void ieee80211_send_pspoll(struct ieee80211_local *local,
+			   struct ieee80211_sub_if_data *sdata)
+{
+	struct ieee80211_if_sta *ifsta = &sdata->u.sta;
+	struct ieee80211_pspoll *pspoll;
+	struct sk_buff *skb;
+	u16 fc;
+
+	skb = dev_alloc_skb(local->hw.extra_tx_headroom + sizeof(*pspoll));
+	if (!skb) {
+		printk(KERN_DEBUG "%s: failed to allocate buffer for "
+		       "pspoll frame\n", sdata->dev->name);
+		return;
+	}
+	skb_reserve(skb, local->hw.extra_tx_headroom);
+
+	pspoll = (struct ieee80211_pspoll *) skb_put(skb, sizeof(*pspoll));
+	memset(pspoll, 0, sizeof(*pspoll));
+	fc = IEEE80211_FTYPE_CTL | IEEE80211_STYPE_PSPOLL;
+	pspoll->frame_control = cpu_to_le16(fc);
+	pspoll->aid = cpu_to_le16(ifsta->aid);
+
+	/* aid in PS-Poll has its two MSBs each set to 1 */
+	pspoll->aid |= cpu_to_le16(1 << 15 | 1 << 14);
+
+	memcpy(pspoll->bssid, ifsta->bssid, ETH_ALEN);
+	memcpy(pspoll->ta, sdata->dev->dev_addr, ETH_ALEN);
+
+	printk(KERN_DEBUG "sending ps-poll");
+
+	ieee80211_tx_skb(sdata, skb, 0);
+
+	return;
+}
+
 /* MLME */
 static void ieee80211_sta_def_wmm_params(struct ieee80211_sub_if_data *sdata,
 					 struct ieee80211_bss *bss)
@@ -1816,9 +1851,8 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
 		directed_tim = ieee80211_check_tim(&elems, ifsta->aid);
 
 		if (directed_tim) {
-			local->hw.conf.flags &= ~IEEE80211_CONF_PS;
-			ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_PS);
-			ieee80211_send_nullfunc(local, sdata, 0);
+			local->pspolling = true;
+			ieee80211_send_pspoll(local, sdata);
 		}
 	}
 
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 9fd9d21..59b0a50 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -740,6 +740,39 @@ ieee80211_rx_h_decrypt(struct ieee80211_rx_data *rx)
 	return result;
 }
 
+static ieee80211_rx_result debug_noinline
+ieee80211_rx_h_check_more_data(struct ieee80211_rx_data *rx)
+{
+	struct ieee80211_local *local;
+	struct ieee80211_hdr *hdr;
+	struct sk_buff *skb;
+
+	local = rx->local;
+	skb = rx->skb;
+	hdr = (struct ieee80211_hdr *) skb->data;
+
+	if (!local->pspolling)
+		return RX_CONTINUE;
+
+	if (!ieee80211_has_fromds(hdr->frame_control))
+		/* this is not from AP */
+		return RX_CONTINUE;
+
+	if (!ieee80211_is_data(hdr->frame_control))
+		return RX_CONTINUE;
+
+	if (!ieee80211_has_moredata(hdr->frame_control)) {
+		/* AP has no more frames buffered for us */
+		local->pspolling = false;
+		return RX_CONTINUE;
+	}
+
+	/* more data bit is set, let's request a new frame from the AP */
+	ieee80211_send_pspoll(local, rx->sdata);
+
+	return RX_CONTINUE;
+}
+
 static void ap_sta_ps_start(struct sta_info *sta)
 {
 	struct ieee80211_sub_if_data *sdata = sta->sdata;
@@ -2006,6 +2039,7 @@ static void ieee80211_invoke_rx_handlers(struct ieee80211_sub_if_data *sdata,
 	CALL_RXH(ieee80211_rx_h_passive_scan)
 	CALL_RXH(ieee80211_rx_h_check)
 	CALL_RXH(ieee80211_rx_h_decrypt)
+	CALL_RXH(ieee80211_rx_h_check_more_data)
 	CALL_RXH(ieee80211_rx_h_sta_process)
 	CALL_RXH(ieee80211_rx_h_defragment)
 	CALL_RXH(ieee80211_rx_h_ps_poll)

[RFC PATCH v2 0/2] mac80211: ps-poll implementation

[Kalle Valo]

Here's my suggestion for how to implement ps-poll in mac80211. Also
this fixes the case when dynamic_ps_timeout is zero.

I decided to use ps-polling when dynamic_ps_timeout is zero. If
userspace sets timeout to zero, it means that it's ready to sacrifice
throughput over power consumption. But in case there throughput is
more, userspace can set timeout to a non-zero value and null frame
wakeup is used instead, throughput is higher but power consumption
also increases.

Most probably this patchset breaks ath9k multicast handling. I
recommend ath9k to try do multicast tim bit handling in hardware, I
would really assume that to be possible. But if that's really
impossible, then it can be done in the driver. But having support for
waking up multicast tim bits in mac80211 is unreliable and complicated
the implementation, I just recommend dropping it.

Open question is that should power save be disabled whenever mac80211
is ps-polling the frames. For example, p54/stlc45xx does not require to
disable power save in that case, it just stays awake long enough to
receive the data frame from the AP. So I did not disable power save
mode in this case, but I would like to hear comments what other
hardware needs.

v2:

o RX_CONTINUE after sending ps-poll frame in ieee80211_rx_h_check_more_data()
o remove leftover debug printk
o use ps-poll only when dynamic_ps_timeout is zero, otherwise null frame
  wakeup is used

---

Kalle Valo (2):
      mac80211: use ps-poll when dynamic power save mode is disabled
      mac80211: remove multicast check from check_tim()


 net/mac80211/ieee80211_i.h |    3 ++
 net/mac80211/mlme.c        |   69 +++++++++++++++++++++++++++++++++++++-------
 net/mac80211/rx.c          |   34 ++++++++++++++++++++++
 3 files changed, 95 insertions(+), 11 deletions(-)

Re: [RFC PATCH v2 0/2] mac80211: ps-poll implementation

[Johannes Berg]

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

On Thu, 2009-01-22 at 13:45 +0200, Kalle Valo wrote:
> Here's my suggestion for how to implement ps-poll in mac80211. Also
> this fixes the case when dynamic_ps_timeout is zero.

Looks good to me.

> I decided to use ps-polling when dynamic_ps_timeout is zero. If
> userspace sets timeout to zero, it means that it's ready to sacrifice
> throughput over power consumption. But in case there throughput is
> more, userspace can set timeout to a non-zero value and null frame
> wakeup is used instead, throughput is higher but power consumption
> also increases.

Not a bad choice.

> Most probably this patchset breaks ath9k multicast handling. I
> recommend ath9k to try do multicast tim bit handling in hardware, I
> would really assume that to be possible. But if that's really
> impossible, then it can be done in the driver. But having support for
> waking up multicast tim bits in mac80211 is unreliable and complicated
> the implementation, I just recommend dropping it.

I agree, we should push this as close to the device as possible.
mac80211 has to defer to a workqueue which adds latency, while if this
really needs to be done in software the driver can do it much faster
because it doesn't necessarily have any generic workqueue requirement
and can possibly even wake the hardware in irq context.

> Open question is that should power save be disabled whenever mac80211
> is ps-polling the frames. For example, p54/stlc45xx does not require to
> disable power save in that case, it just stays awake long enough to
> receive the data frame from the AP. So I did not disable power save
> mode in this case, but I would like to hear comments what other
> hardware needs.

I just checked, Broadcom's hardware/firmware definitely requires doing
this in software.

johannes

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

Re: [RFC PATCH v2 0/2] mac80211: ps-poll implementation

[Kalle Valo]

"Johannes Berg" <johannes@sipsolutions.net> writes:

>> Open question is that should power save be disabled whenever mac80211
>> is ps-polling the frames. For example, p54/stlc45xx does not require to
>> disable power save in that case, it just stays awake long enough to
>> receive the data frame from the AP. So I did not disable power save
>> mode in this case, but I would like to hear comments what other
>> hardware needs.
>
> I just checked, Broadcom's hardware/firmware definitely requires doing
> this in software.

Ok. The problem is that stlc45xx/p54spi requires us to send a null
frame every time we enable power save and that's causing problems, at
least that's my current theory. So I need to solve this somehow, I
need to think this more.

But can we still apply these patches? Because b43 doesn't support
power save at all, and ath9k with dynamic power save disabled was
already broken before my patches, I consider these patches as a step
forward. And I would like to go forward one small step at a time,
maintaining huge patches myself until all issues are fixed is quite
difficult.

-- 
Kalle Valo

Re: [RFC PATCH v2 0/2] mac80211: ps-poll implementation

[Johannes Berg]

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

On Fri, 2009-01-23 at 11:31 +0200, Kalle Valo wrote:

> Ok. The problem is that stlc45xx/p54spi requires us to send a null
> frame every time we enable power save and that's causing problems, at
> least that's my current theory. So I need to solve this somehow, I
> need to think this more.

True.

> But can we still apply these patches? Because b43 doesn't support
> power save at all, and ath9k with dynamic power save disabled was
> already broken before my patches, I consider these patches as a step
> forward. And I would like to go forward one small step at a time,
> maintaining huge patches myself until all issues are fixed is quite
> difficult.

Yes, agree, can you repost without RFC and the printk removed (and
possibly rebased)?

johannes

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

Re: [RFC PATCH v2 0/2] mac80211: ps-poll implementation

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Fri, 2009-01-23 at 11:31 +0200, Kalle Valo wrote:
>
>> Ok. The problem is that stlc45xx/p54spi requires us to send a null
>> frame every time we enable power save and that's causing problems, at
>> least that's my current theory. So I need to solve this somehow, I
>> need to think this more.
>
> True.
>
>> But can we still apply these patches? Because b43 doesn't support
>> power save at all, and ath9k with dynamic power save disabled was
>> already broken before my patches, I consider these patches as a step
>> forward. And I would like to go forward one small step at a time,
>> maintaining huge patches myself until all issues are fixed is quite
>> difficult.
>
> Yes, agree, can you repost without RFC and the printk removed (and
> possibly rebased)?

Sure thing. I'm rebasing it right now.

-- 
Kalle Valo