[RFT/FYI] mac80211: revert on-channel work optimisations

[RFT/FYI] mac80211: revert on-channel work optimisations

[Johannes Berg]

FYI -- I'm going to test this a bit more but I am going to put it in.
The code is a mess -- look at how much code I remove below (and that's
after everybody elses cleanups!) for a dubious optimisation.

I agree that we should address this and we need to really do this to not
mess up our aggregation state, but the current code is too complex and
causing too many issues. We also need to think about this in the context
of multi-virtual-channel support.

johannes



From: Johannes Berg <johannes.berg@intel.com>

The on-channel work optimisations have caused a
number of issues, and the code is unfortunately
very complex and almost impossible to follow.
Instead of attempting to put in more workarounds
let's just remove those optimisations, we can
work on them again later.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
This applies on top of Stanislaw's three patches and
my patch from today to remove the same mess from the
scan code.

 net/mac80211/ieee80211_i.h |    2 
 net/mac80211/main.c        |   41 ------------------
 net/mac80211/offchannel.c  |    9 +---
 net/mac80211/scan.c        |    4 -
 net/mac80211/work.c        |   99 +++------------------------------------------
 5 files changed, 13 insertions(+), 142 deletions(-)

--- a/net/mac80211/work.c	2011-11-08 18:04:34.000000000 +0100
+++ b/net/mac80211/work.c	2011-11-08 18:05:52.000000000 +0100
@@ -881,44 +881,6 @@ static void ieee80211_work_rx_queued_mgm
 	kfree_skb(skb);
 }
 
-static bool ieee80211_work_ct_coexists(enum nl80211_channel_type wk_ct,
-				       enum nl80211_channel_type oper_ct)
-{
-	switch (wk_ct) {
-	case NL80211_CHAN_NO_HT:
-		return true;
-	case NL80211_CHAN_HT20:
-		if (oper_ct != NL80211_CHAN_NO_HT)
-			return true;
-		return false;
-	case NL80211_CHAN_HT40MINUS:
-	case NL80211_CHAN_HT40PLUS:
-		return (wk_ct == oper_ct);
-	}
-	WARN_ON(1); /* shouldn't get here */
-	return false;
-}
-
-static enum nl80211_channel_type
-ieee80211_calc_ct(enum nl80211_channel_type wk_ct,
-		  enum nl80211_channel_type oper_ct)
-{
-	switch (wk_ct) {
-	case NL80211_CHAN_NO_HT:
-		return oper_ct;
-	case NL80211_CHAN_HT20:
-		if (oper_ct != NL80211_CHAN_NO_HT)
-			return oper_ct;
-		return wk_ct;
-	case NL80211_CHAN_HT40MINUS:
-	case NL80211_CHAN_HT40PLUS:
-		return wk_ct;
-	}
-	WARN_ON(1); /* shouldn't get here */
-	return wk_ct;
-}
-
-
 static void ieee80211_work_timer(unsigned long data)
 {
 	struct ieee80211_local *local = (void *) data;
@@ -969,40 +931,12 @@ static void ieee80211_work_work(struct w
 		}
 
 		if (!started && !local->tmp_channel) {
-			bool on_oper_chan, on_oper_chan2;
-			enum nl80211_channel_type wk_ct;
-
-			on_oper_chan = ieee80211_cfg_on_oper_channel(local);
-
-			/* Work with existing channel type if possible. */
-			wk_ct = wk->chan_type;
-			if (wk->chan == local->hw.conf.channel)
-				wk_ct = ieee80211_calc_ct(wk->chan_type,
-						local->hw.conf.channel_type);
+			ieee80211_offchannel_stop_vifs(local, true);
 
 			local->tmp_channel = wk->chan;
-			local->tmp_channel_type = wk_ct;
-			/*
-			 * Leave the station vifs in awake mode if they
-			 * happen to be on the same channel as
-			 * the requested channel.
-			 */
-			on_oper_chan2 = ieee80211_cfg_on_oper_channel(local);
-			if (on_oper_chan != on_oper_chan2) {
-				if (on_oper_chan2) {
-					/* going off oper channel, PS too */
-					ieee80211_offchannel_stop_vifs(local,
-								       true);
-					ieee80211_hw_config(local, 0);
-				} else {
-					/* going on channel, but leave PS
-					 * off-channel. */
-					ieee80211_hw_config(local, 0);
-					ieee80211_offchannel_return(local,
-								    true,
-								    false);
-				}
-			}
+			local->tmp_channel_type = wk->chan_type;
+
+			ieee80211_hw_config(local, 0);
 
 			started = true;
 			wk->timeout = jiffies;
@@ -1071,34 +1005,17 @@ static void ieee80211_work_work(struct w
 	list_for_each_entry(wk, &local->work_list, list) {
 		if (!wk->started)
 			continue;
-		if (wk->chan != local->tmp_channel)
-			continue;
-		if (!ieee80211_work_ct_coexists(wk->chan_type,
-						local->tmp_channel_type))
+		if (wk->chan != local->tmp_channel ||
+		    wk->chan_type != local->tmp_channel_type)
 			continue;
 		remain_off_channel = true;
 	}
 
 	if (!remain_off_channel && local->tmp_channel) {
 		local->tmp_channel = NULL;
-		/* If tmp_channel wasn't operating channel, then
-		 * we need to go back on-channel.
-		 * NOTE:  If we can ever be here while scannning,
-		 * or if the hw_config() channel config logic changes,
-		 * then we may need to do a more thorough check to see if
-		 * we still need to do a hardware config.  Currently,
-		 * we cannot be here while scanning, however.
-		 */
-		if (!ieee80211_cfg_on_oper_channel(local))
-			ieee80211_hw_config(local, 0);
+		ieee80211_hw_config(local, 0);
 
-		/* At the least, we need to disable offchannel_ps,
-		 * so just go ahead and run the entire offchannel
-		 * return logic here.  We *could* skip enabling
-		 * beaconing if we were already on-oper-channel
-		 * as a future optimization.
-		 */
-		ieee80211_offchannel_return(local, true, true);
+		ieee80211_offchannel_return(local, true);
 
 		/* give connection some time to breathe */
 		run_again(local, jiffies + HZ/2);
--- a/net/mac80211/ieee80211_i.h	2011-11-08 18:05:51.000000000 +0100
+++ b/net/mac80211/ieee80211_i.h	2011-11-08 18:05:52.000000000 +0100
@@ -1139,13 +1139,11 @@ int ieee80211_request_sched_scan_stop(st
 void ieee80211_sched_scan_stopped_work(struct work_struct *work);
 
 /* off-channel helpers */
-bool ieee80211_cfg_on_oper_channel(struct ieee80211_local *local);
 void ieee80211_offchannel_enable_all_ps(struct ieee80211_local *local,
 					bool tell_ap);
 void ieee80211_offchannel_stop_vifs(struct ieee80211_local *local,
 				    bool offchannel_ps_enable);
 void ieee80211_offchannel_return(struct ieee80211_local *local,
-				 bool enable_beaconing,
 				 bool offchannel_ps_disable);
 void ieee80211_hw_roc_setup(struct ieee80211_local *local);
 
--- a/net/mac80211/offchannel.c	2011-11-08 17:51:57.000000000 +0100
+++ b/net/mac80211/offchannel.c	2011-11-08 18:05:52.000000000 +0100
@@ -155,7 +155,6 @@ void ieee80211_offchannel_enable_all_ps(
 }
 
 void ieee80211_offchannel_return(struct ieee80211_local *local,
-				 bool enable_beaconing,
 				 bool offchannel_ps_disable)
 {
 	struct ieee80211_sub_if_data *sdata;
@@ -187,11 +186,9 @@ void ieee80211_offchannel_return(struct
 			netif_tx_wake_all_queues(sdata->dev);
 		}
 
-		/* Check to see if we should re-enable beaconing */
-		if (enable_beaconing &&
-		    (sdata->vif.type == NL80211_IFTYPE_AP ||
-		     sdata->vif.type == NL80211_IFTYPE_ADHOC ||
-		     sdata->vif.type == NL80211_IFTYPE_MESH_POINT))
+		if (sdata->vif.type == NL80211_IFTYPE_AP ||
+		    sdata->vif.type == NL80211_IFTYPE_ADHOC ||
+		    sdata->vif.type == NL80211_IFTYPE_MESH_POINT)
 			ieee80211_bss_info_change_notify(
 				sdata, BSS_CHANGED_BEACON_ENABLED);
 	}
--- a/net/mac80211/main.c	2011-11-08 18:04:34.000000000 +0100
+++ b/net/mac80211/main.c	2011-11-08 18:05:52.000000000 +0100
@@ -92,47 +92,6 @@ static void ieee80211_reconfig_filter(st
 	ieee80211_configure_filter(local);
 }
 
-/*
- * Returns true if we are logically configured to be on
- * the operating channel AND the hardware-conf is currently
- * configured on the operating channel.  Compares channel-type
- * as well.
- */
-bool ieee80211_cfg_on_oper_channel(struct ieee80211_local *local)
-{
-	struct ieee80211_channel *chan;
-	enum nl80211_channel_type channel_type;
-
-	/* This logic needs to match logic in ieee80211_hw_config */
-	if (local->scan_channel) {
-		chan = local->scan_channel;
-		/* If scanning on oper channel, use whatever channel-type
-		 * is currently in use.
-		 */
-		if (chan == local->oper_channel)
-			channel_type = local->_oper_channel_type;
-		else
-			channel_type = NL80211_CHAN_NO_HT;
-	} else if (local->tmp_channel) {
-		chan = local->tmp_channel;
-		channel_type = local->tmp_channel_type;
-	} else {
-		chan = local->oper_channel;
-		channel_type = local->_oper_channel_type;
-	}
-
-	if (chan != local->oper_channel ||
-	    channel_type != local->_oper_channel_type)
-		return false;
-
-	/* Check current hardware-config against oper_channel. */
-	if (local->oper_channel != local->hw.conf.channel ||
-	    local->_oper_channel_type != local->hw.conf.channel_type)
-		return false;
-
-	return true;
-}
-
 int ieee80211_hw_config(struct ieee80211_local *local, u32 changed)
 {
 	struct ieee80211_channel *chan;
--- a/net/mac80211/scan.c	2011-11-08 18:05:51.000000000 +0100
+++ b/net/mac80211/scan.c	2011-11-08 18:05:52.000000000 +0100
@@ -296,7 +296,7 @@ static void __ieee80211_scan_completed(s
 	if (!was_hw_scan) {
 		ieee80211_configure_filter(local);
 		drv_sw_scan_complete(local);
-		ieee80211_offchannel_return(local, true, true);
+		ieee80211_offchannel_return(local, true);
 	}
 
 	ieee80211_recalc_idle(local);
@@ -601,7 +601,7 @@ static void ieee80211_scan_state_suspend
 	 * in off-channel state..will put that back
 	 * on-channel at the end of scanning.
 	 */
-	ieee80211_offchannel_return(local, true, false);
+	ieee80211_offchannel_return(local, false);
 
 	*next_delay = HZ / 5;
 	/* afterwards, resume scan & go to next channel */

Re: [RFT/FYI] mac80211: revert on-channel work optimisations

[Ben Greear]

On 11/08/2011 09:10 AM, Johannes Berg wrote:
> FYI -- I'm going to test this a bit more but I am going to put it in.
> The code is a mess -- look at how much code I remove below (and that's
> after everybody elses cleanups!) for a dubious optimisation.
>
> I agree that we should address this and we need to really do this to not
> mess up our aggregation state, but the current code is too complex and
> causing too many issues. We also need to think about this in the context
> of multi-virtual-channel support.

Well crap.  Why don't you try to fix it right instead?

I'll probably end up carrying this in my own tree so
that multiple vifs work well and don't constantly
reset the ath9k causing it to shit itself...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [RFT/FYI] mac80211: revert on-channel work optimisations

[Johannes Berg]

On Tue, 2011-11-08 at 09:17 -0800, Ben Greear wrote:
> On 11/08/2011 09:10 AM, Johannes Berg wrote:
> > FYI -- I'm going to test this a bit more but I am going to put it in.
> > The code is a mess -- look at how much code I remove below (and that's
> > after everybody elses cleanups!) for a dubious optimisation.
> >
> > I agree that we should address this and we need to really do this to not
> > mess up our aggregation state, but the current code is too complex and
> > causing too many issues. We also need to think about this in the context
> > of multi-virtual-channel support.
> 
> Well crap.  Why don't you try to fix it right instead?

Can't even understand it, I have a better chance just rewriting it.

Like I said -- I know I'll have to do that, but I need to think about
this in the context of using different channels on different virtual
interfaces etc. and probably rework the channel config logic in mac80211
significantly...

johannes

Re: [RFT/FYI] mac80211: revert on-channel work optimisations

[Ben Greear]

On 11/08/2011 09:18 AM, Johannes Berg wrote:
> On Tue, 2011-11-08 at 09:17 -0800, Ben Greear wrote:
>> On 11/08/2011 09:10 AM, Johannes Berg wrote:
>>> FYI -- I'm going to test this a bit more but I am going to put it in.
>>> The code is a mess -- look at how much code I remove below (and that's
>>> after everybody elses cleanups!) for a dubious optimisation.
>>>
>>> I agree that we should address this and we need to really do this to not
>>> mess up our aggregation state, but the current code is too complex and
>>> causing too many issues. We also need to think about this in the context
>>> of multi-virtual-channel support.
>>
>> Well crap.  Why don't you try to fix it right instead?
>
> Can't even understand it, I have a better chance just rewriting it.

That's fine by me, I found the code complex as well.  All the tmp
and scan and active channel pointers makes for a real mess.  But if
you want multiple vifs to work well, then you really need to be able
to continue to function on-channel when some other vif is scanning
on that channel.  My use of the wifi stack requires this to work,
so if it takes any significant time to get the new code in I'm going
to have to stick with my complex crap.

> Like I said -- I know I'll have to do that, but I need to think about
> this in the context of using different channels on different virtual
> interfaces etc. and probably rework the channel config logic in mac80211
> significantly...

Well, good luck with that.  I'll test patches if you post them.

Thanks,
Ben

>
> johannes


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [RFT/FYI] mac80211: revert on-channel work optimisations

[Johannes Berg]

On Tue, 2011-11-08 at 09:25 -0800, Ben Greear wrote:

> That's fine by me, I found the code complex as well.  All the tmp
> and scan and active channel pointers makes for a real mess.  

Indeed.

> But if
> you want multiple vifs to work well, then you really need to be able
> to continue to function on-channel when some other vif is scanning
> on that channel.  My use of the wifi stack requires this to work,
> so if it takes any significant time to get the new code in I'm going
> to have to stick with my complex crap.

And I'm not saying you shouldn't, but I think for upstream right now
it's not really a good thing. I wish I could say otherwise but given the
bugs we have here etc. I don't really feel very confident.

Now with multi-channel stuff it's all going to change anyway, each vif
will have its own channel and the device will have to mostly sort out
the scheduling by itself, ath9k will have to do some tricks in the
driver, maybe with some help in mac80211, and off-channel stuff will be
interesting too ...

johannes

Re: [RFT/FYI] mac80211: revert on-channel work optimisations

[Ben Greear]

On 11/08/2011 09:56 AM, Johannes Berg wrote:
> On Tue, 2011-11-08 at 09:25 -0800, Ben Greear wrote:
>
>> That's fine by me, I found the code complex as well.  All the tmp
>> and scan and active channel pointers makes for a real mess.
>
> Indeed.
>
>> But if
>> you want multiple vifs to work well, then you really need to be able
>> to continue to function on-channel when some other vif is scanning
>> on that channel.  My use of the wifi stack requires this to work,
>> so if it takes any significant time to get the new code in I'm going
>> to have to stick with my complex crap.
>
> And I'm not saying you shouldn't, but I think for upstream right now
> it's not really a good thing. I wish I could say otherwise but given the
> bugs we have here etc. I don't really feel very confident.

Are there any open bugs right now that seem to be because of the
scanning and work optimizations, or are you just paranoid that
there are more that are not found or well understood yet?

If there is something reported, I'll make a try at fixing it.

> Now with multi-channel stuff it's all going to change anyway, each vif
> will have its own channel and the device will have to mostly sort out
> the scheduling by itself, ath9k will have to do some tricks in the
> driver, maybe with some help in mac80211, and off-channel stuff will be
> interesting too ...

Is someone already working on this, or planning to do so soon?  At least
to me, the multi-channel stuff appears fundamentally broken since I'm
not aware of any NIC that can listen in two channels at once.  Flipping
from channel to channel seems like at best it is going to give bad latency,
and probably lots of packet loss as well.  What is the use-case for this
feature, anyway?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [RFT/FYI] mac80211: revert on-channel work optimisations

[Johannes Berg]

On Tue, 2011-11-08 at 10:08 -0800, Ben Greear wrote:

> >> But if
> >> you want multiple vifs to work well, then you really need to be able
> >> to continue to function on-channel when some other vif is scanning
> >> on that channel.  My use of the wifi stack requires this to work,
> >> so if it takes any significant time to get the new code in I'm going
> >> to have to stick with my complex crap.
> >
> > And I'm not saying you shouldn't, but I think for upstream right now
> > it's not really a good thing. I wish I could say otherwise but given the
> > bugs we have here etc. I don't really feel very confident.
> 
> Are there any open bugs right now that seem to be because of the
> scanning and work optimizations, or are you just paranoid that
> there are more that are not found or well understood yet?
> 
> If there is something reported, I'll make a try at fixing it.

I was looking at RH bug 731365 but I think Eliad's patches should have
fixed that. But generally, that code just makes me nervous, in
particular ieee80211_cfg_on_oper_channel(). I think all of this should
be a lot simpler, and if it isn't that's probably due to *other* bugs
this is working around.

> > Now with multi-channel stuff it's all going to change anyway, each vif
> > will have its own channel and the device will have to mostly sort out
> > the scheduling by itself, ath9k will have to do some tricks in the
> > driver, maybe with some help in mac80211, and off-channel stuff will be
> > interesting too ...
> 
> Is someone already working on this, or planning to do so soon?  

I am planning to.

> At least
> to me, the multi-channel stuff appears fundamentally broken since I'm
> not aware of any NIC that can listen in two channels at once.  Flipping
> from channel to channel seems like at best it is going to give bad latency,
> and probably lots of packet loss as well.  What is the use-case for this
> feature, anyway?

Oh, well, for example P2P printing to a printer that's already on
channel 5 while connected to an AP that's already on channel 11. That'd
be temporary, but any quality of service degradation is still better
than not being able to print.

johannes

Re: [RFT/FYI] mac80211: revert on-channel work optimisations

[Stanislaw Gruszka]

On Tue, Nov 08, 2011 at 07:38:51PM +0100, Johannes Berg wrote:
> I was looking at RH bug 731365 but I think Eliad's patches should have
> fixed that. But generally, that code just makes me nervous, in
> particular ieee80211_cfg_on_oper_channel(). I think all of this should
> be a lot simpler, and if it isn't that's probably due to *other* bugs
> this is working around.

So, can proceed with that revert? We just get confirmation in 
RH bug 731365, that it fix reproducible rate_control_send_low
WARNING issue (also is probable that it fix some rtlwifi problems,
but I do not have clear confirmation about that yet).

Stanislaw

Re: [RFT/FYI] mac80211: revert on-channel work optimisations

[Johannes Berg]

On Fri, 2011-11-25 at 12:27 +0100, Stanislaw Gruszka wrote:
> On Tue, Nov 08, 2011 at 07:38:51PM +0100, Johannes Berg wrote:
> > I was looking at RH bug 731365 but I think Eliad's patches should have
> > fixed that. But generally, that code just makes me nervous, in
> > particular ieee80211_cfg_on_oper_channel(). I think all of this should
> > be a lot simpler, and if it isn't that's probably due to *other* bugs
> > this is working around.
> 
> So, can proceed with that revert? We just get confirmation in 
> RH bug 731365, that it fix reproducible rate_control_send_low
> WARNING issue (also is probable that it fix some rtlwifi problems,
> but I do not have clear confirmation about that yet).

Ok let's do it -- I have this patch for upstream, can you later provide
the one for stable?

johannes

Re: [RFT/FYI] mac80211: revert on-channel work optimisations

[Johannes Berg]

On Tue, 2011-11-08 at 09:17 -0800, Ben Greear wrote:
> On 11/08/2011 09:10 AM, Johannes Berg wrote:
> > FYI -- I'm going to test this a bit more but I am going to put it in.
> > The code is a mess -- look at how much code I remove below (and that's
> > after everybody elses cleanups!) for a dubious optimisation.
> >
> > I agree that we should address this and we need to really do this to not
> > mess up our aggregation state, but the current code is too complex and
> > causing too many issues. We also need to think about this in the context
> > of multi-virtual-channel support.
> 
> Well crap.  Why don't you try to fix it right instead?
> 
> I'll probably end up carrying this in my own tree so
> that multiple vifs work well and don't constantly
> reset the ath9k causing it to shit itself...

Given the auth/assoc redesign that went in now, are you still carrying
this? Does the redesign address your problem?

johannes

Re: [RFT/FYI] mac80211: revert on-channel work optimisations

[Ben Greear]

On 02/17/2012 07:44 AM, Johannes Berg wrote:
> On Tue, 2011-11-08 at 09:17 -0800, Ben Greear wrote:
>> On 11/08/2011 09:10 AM, Johannes Berg wrote:
>>> FYI -- I'm going to test this a bit more but I am going to put it in.
>>> The code is a mess -- look at how much code I remove below (and that's
>>> after everybody elses cleanups!) for a dubious optimisation.
>>>
>>> I agree that we should address this and we need to really do this to not
>>> mess up our aggregation state, but the current code is too complex and
>>> causing too many issues. We also need to think about this in the context
>>> of multi-virtual-channel support.
>>
>> Well crap.  Why don't you try to fix it right instead?
>>
>> I'll probably end up carrying this in my own tree so
>> that multiple vifs work well and don't constantly
>> reset the ath9k causing it to shit itself...
>
> Given the auth/assoc redesign that went in now, are you still carrying
> this? Does the redesign address your problem?

I haven't looked yet...still stuck back on 3.0 kernel for the
most part.

I should be moving to 3.3 sometime soon, and will see how it works.

I was thinking that I would ignore the work logic for now and probably
just focus on re-applying the on-channel scan optimization first.

Are you done, or mostly done with the re-architecture you were working on?

I know you didn't like the scan optimization from before...do you have any
ideas on how it might be done more to your liking?

Thanks,
Ben


>
> johannes


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [RFT/FYI] mac80211: revert on-channel work optimisations

[Johannes Berg]

On Fri, 2012-02-17 at 08:13 -0800, Ben Greear wrote:

> > Given the auth/assoc redesign that went in now, are you still carrying
> > this? Does the redesign address your problem?
> 
> I haven't looked yet...still stuck back on 3.0 kernel for the
> most part.
> 
> I should be moving to 3.3 sometime soon, and will see how it works.
> 
> I was thinking that I would ignore the work logic for now and probably
> just focus on re-applying the on-channel scan optimization first.
> 
> Are you done, or mostly done with the re-architecture you were working on?

Yes, I'm done.

> I know you didn't like the scan optimization from before...do you have any
> ideas on how it might be done more to your liking?

I, umm, don't even remember what that was about :)

johannes

Re: [RFT/FYI] mac80211: revert on-channel work optimisations

[Ben Greear]

On 02/17/2012 10:19 AM, Johannes Berg wrote:
> On Fri, 2012-02-17 at 08:13 -0800, Ben Greear wrote:
>
>>> Given the auth/assoc redesign that went in now, are you still carrying
>>> this? Does the redesign address your problem?
>>
>> I haven't looked yet...still stuck back on 3.0 kernel for the
>> most part.
>>
>> I should be moving to 3.3 sometime soon, and will see how it works.
>>
>> I was thinking that I would ignore the work logic for now and probably
>> just focus on re-applying the on-channel scan optimization first.
>>
>> Are you done, or mostly done with the re-architecture you were working on?
>
> Yes, I'm done.
>
>> I know you didn't like the scan optimization from before...do you have any
>> ideas on how it might be done more to your liking?
>
> I, umm, don't even remember what that was about :)

The basic idea is that if the user requests that we only
scan a single channel, and that channel is the operating channel,
we should be able to scan without interrupting any other
packet transmission/reception, and without kicking the NIC to make it go off/on
channel, etc.

Basically I had to complicate the scan state machine
in order to minimize going off-channel (if indeed we are only
scanning one current channel).

I'd want to re-add the logic that let us receive pkts while
scanning (so long as we are scanning on the oper-channel)
as well.

Might be a while before I can get back to this, but I'll
let you know when I get started if no one beats me to it.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [RFT/FYI] mac80211: revert on-channel work optimisations

[Stanislaw Gruszka]

On Fri, Feb 17, 2012 at 10:38:54AM -0800, Ben Greear wrote:
> On 02/17/2012 10:19 AM, Johannes Berg wrote:
> >On Fri, 2012-02-17 at 08:13 -0800, Ben Greear wrote:
> >
> >>>Given the auth/assoc redesign that went in now, are you still carrying
> >>>this? Does the redesign address your problem?
> >>
> >>I haven't looked yet...still stuck back on 3.0 kernel for the
> >>most part.
> >>
> >>I should be moving to 3.3 sometime soon, and will see how it works.
> >>
> >>I was thinking that I would ignore the work logic for now and probably
> >>just focus on re-applying the on-channel scan optimization first.
> >>
> >>Are you done, or mostly done with the re-architecture you were working on?
> >
> >Yes, I'm done.
> >
> >>I know you didn't like the scan optimization from before...do you have any
> >>ideas on how it might be done more to your liking?
> >
> >I, umm, don't even remember what that was about :)
> 
> The basic idea is that if the user requests that we only
> scan a single channel, and that channel is the operating channel,
> we should be able to scan without interrupting any other
> packet transmission/reception, and without kicking the NIC to make it go off/on
> channel, etc.
> 
> Basically I had to complicate the scan state machine
> in order to minimize going off-channel (if indeed we are only
> scanning one current channel).
I think no change in scan state machine in needed at all. It could be
simply marked as another type of scan i.e. SCAN_CURRENT_CHAN.
Configure filters at start, send probe request if active, 
add additional flag check in rx_handlers, reconfigure filters
at end.

Stanislaw