All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mac80211: Remove superfluous ieee80211_rx_h_remove_qos_control
@ 2011-12-19 10:39 Helmut Schaa
  2011-12-19 15:56 ` Johannes Berg
  0 siblings, 1 reply; 3+ messages in thread
From: Helmut Schaa @ 2011-12-19 10:39 UTC (permalink / raw
  To: linux-wireless; +Cc: linville, johannes, Helmut Schaa

This seems to not serve any purpose anymore, at least all frame
processing afterwards seems to be able to deal with QoS frames. So,
let's save the expensive memmove and just leave the QoS header in the
802.11 frame for further processing.

Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---

It wouldn't hurt if a second pair of eyes looks through the rx path
to see if there's any possible problem with QoS frames in later rx
handlers.

I tried AP and STA mode and couldn't see any problems yet.

Thanks,
Helmut

 net/mac80211/rx.c |   20 --------------------
 1 files changed, 0 insertions(+), 20 deletions(-)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 8418f66..0ff0481 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1576,25 +1576,6 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)
 	return RX_CONTINUE;
 }
 
-static ieee80211_rx_result debug_noinline
-ieee80211_rx_h_remove_qos_control(struct ieee80211_rx_data *rx)
-{
-	u8 *data = rx->skb->data;
-	struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)data;
-
-	if (!ieee80211_is_data_qos(hdr->frame_control))
-		return RX_CONTINUE;
-
-	/* remove the qos control field, update frame type and meta-data */
-	memmove(data + IEEE80211_QOS_CTL_LEN, data,
-		ieee80211_hdrlen(hdr->frame_control) - IEEE80211_QOS_CTL_LEN);
-	hdr = (struct ieee80211_hdr *)skb_pull(rx->skb, IEEE80211_QOS_CTL_LEN);
-	/* change frame type to non QOS */
-	hdr->frame_control &= ~cpu_to_le16(IEEE80211_STYPE_QOS_DATA);
-
-	return RX_CONTINUE;
-}
-
 static int
 ieee80211_802_1x_port_control(struct ieee80211_rx_data *rx)
 {
@@ -2669,7 +2650,6 @@ static void ieee80211_rx_handlers(struct ieee80211_rx_data *rx)
 		if (ieee80211_vif_is_mesh(&rx->sdata->vif))
 			CALL_RXH(ieee80211_rx_h_mesh_fwding);
 #endif
-		CALL_RXH(ieee80211_rx_h_remove_qos_control)
 		CALL_RXH(ieee80211_rx_h_amsdu)
 		CALL_RXH(ieee80211_rx_h_data)
 		CALL_RXH(ieee80211_rx_h_ctrl);
-- 
1.7.7


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] mac80211: Remove superfluous ieee80211_rx_h_remove_qos_control
  2011-12-19 10:39 [PATCH] mac80211: Remove superfluous ieee80211_rx_h_remove_qos_control Helmut Schaa
@ 2011-12-19 15:56 ` Johannes Berg
  2011-12-19 16:38   ` Helmut Schaa
  0 siblings, 1 reply; 3+ messages in thread
From: Johannes Berg @ 2011-12-19 15:56 UTC (permalink / raw
  To: Helmut Schaa; +Cc: linux-wireless, linville

On Mon, 2011-12-19 at 11:39 +0100, Helmut Schaa wrote:
> This seems to not serve any purpose anymore, at least all frame
> processing afterwards seems to be able to deal with QoS frames. So,
> let's save the expensive memmove and just leave the QoS header in the
> 802.11 frame for further processing.
> 
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
> ---
> 
> It wouldn't hurt if a second pair of eyes looks through the rx path
> to see if there's any possible problem with QoS frames in later rx
> handlers.

Ok, but I'm on vacation until next year, so I don't know if I'll get to
it. In principle, this seems fine, but I'd feel more comfortable if
somebody else took another look. Not that I don't trust you, just more
eyes see more things :-)

johannes


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] mac80211: Remove superfluous ieee80211_rx_h_remove_qos_control
  2011-12-19 15:56 ` Johannes Berg
@ 2011-12-19 16:38   ` Helmut Schaa
  0 siblings, 0 replies; 3+ messages in thread
From: Helmut Schaa @ 2011-12-19 16:38 UTC (permalink / raw
  To: Johannes Berg; +Cc: linux-wireless, linville

On Mon, Dec 19, 2011 at 4:56 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2011-12-19 at 11:39 +0100, Helmut Schaa wrote:
>> This seems to not serve any purpose anymore, at least all frame
>> processing afterwards seems to be able to deal with QoS frames. So,
>> let's save the expensive memmove and just leave the QoS header in the
>> 802.11 frame for further processing.
>>
>> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
>> ---
>>
>> It wouldn't hurt if a second pair of eyes looks through the rx path
>> to see if there's any possible problem with QoS frames in later rx
>> handlers.
>
> Ok, but I'm on vacation until next year, so I don't know if I'll get to
> it.

Sure, have a nice holiday.

> In principle, this seems fine, but I'd feel more comfortable if
> somebody else took another look. Not that I don't trust you, just more
> eyes see more things :-)

No worries, I'd also like to have somebody else looking through
the code since it's not quite a trivial change.

Helmut

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-12-19 16:38 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-19 10:39 [PATCH] mac80211: Remove superfluous ieee80211_rx_h_remove_qos_control Helmut Schaa
2011-12-19 15:56 ` Johannes Berg
2011-12-19 16:38   ` Helmut Schaa

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.