linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH v7] mac80211: Optimize scans on current operating channel.
Date: Tue, 01 Feb 2011 08:39:30 -0800	[thread overview]
Message-ID: <4D483742.8030108@candelatech.com> (raw)
In-Reply-To: <201102011631.51405.helmut.schaa@googlemail.com>

On 02/01/2011 07:31 AM, Helmut Schaa wrote:
> Hi Ben,
>
> looks as if your special case (only scanning the operating channel) would be
> covered quite well with this patch. However, in cases where we scan multiple
> channels consecutively (including the operating channel) the operating channel
> might get scanned (if the previous scan channel was off channel and we still
> got time left for another channel to scan) without reenabling the interfaces
> (beaconing, waking up etc.). It wasn't like this before your patch, so that
> shouldn't prevent your optimization from being merged :) but might be
> considered in the future.

Yes.  In particular, I think it would be nice to re-order the scan
channels so that the first channel scanned is the operating channel.
That should optimize things to do as few on/off channel operations
as possible, without adding any more complexity to the scan
state machine.

>
> Am Montag, 31. Januar 2011 schrieb greearb@candelatech.com:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> This should decrease un-necessary flushes, on/off channel work,
>> and channel changes in cases where the only scanned channel is
>> the current operating channel.
>>
>> * Removes SCAN_OFF_CHANNEL flag, uses SDATA_STATE_OFFCHANNEL
>>    and is-scanning flags instead.
>
> Nice!
>
>> * Add helper method to determine if we are currently configured
>>    for the operating channel.
>>
>> * Do no blindly go off/on channel in work.c  Instead, only call
>>    appropriate on/off code when we really need to change channels.
>>
>> * Consolidate ieee80211_offchannel_stop_station and
>>    ieee80211_offchannel_stop_beaconing, call it
>>    ieee80211_offchannel_stop_vifs instead.
>>
>> * Accept non-beacon frames when scanning, even if off-channel.
>
> As far as I can see ieee80211_scan_rx will pass the frame up _only_
> if we are on-channel. Is the comment wrong?

I believe I was talking about this particular piece of code, but
the scan_rx is going to purge any pkts that are not scan results
when not on channel, so that comment is wrong about the off-channel
bit.

+++ b/net/mac80211/rx.c
 > @@ -409,16 +409,10 @@ ieee80211_rx_h_passive_scan(struct ieee80211_rx_data *rx)
 >  	if (likely(!(status->rx_flags & IEEE80211_RX_IN_SCAN)))
 >  		return RX_CONTINUE;
 >
 > -	if (test_bit(SCAN_HW_SCANNING, &local->scanning))
 > +	if (test_bit(SCAN_HW_SCANNING, &local->scanning) ||
 > +	    test_bit(SCAN_SW_SCANNING, &local->scanning))
 >  		return ieee80211_scan_rx(rx->sdata, skb);
 >
 > -	if (test_bit(SCAN_SW_SCANNING, &local->scanning)) {
 > -		/* drop all the other packets during a software scan anyway */
 > -		if (ieee80211_scan_rx(rx->sdata, skb) != RX_QUEUED)
 > -			dev_kfree_skb(skb);
 > -		return RX_QUEUED;
 > -	}
 > -


>> @@ -293,15 +300,25 @@ static void __ieee80211_scan_completed_finish(struct ieee80211_hw *hw,
>>   					      bool was_hw_scan)
>>   {
>>   	struct ieee80211_local *local = hw_to_local(hw);
>> +	bool ooc;
>> +
>> +	mutex_lock(&local->mtx);
>> +	ooc = ieee80211_cfg_on_oper_channel(local);
>> +
>> +	if (was_hw_scan || !ooc)
>> +		ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
>>
>> -	ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
>>   	if (!was_hw_scan) {
>> +		bool ooc2;
>>   		ieee80211_configure_filter(local);
>>   		drv_sw_scan_complete(local);
>> -		ieee80211_offchannel_return(local, true);
>> +		ooc2 = ieee80211_cfg_on_oper_channel(local);
>> +		/* We should always be on-channel at this point. */
>> +		WARN_ON(!ooc2);
>> +		if (ooc2&&  (ooc != ooc2))
>> +			ieee80211_offchannel_return(local, true);
>
> Is this additional check necessary? Looks as if that can only happen
> if the call to ieee80211_hw_config failes, right? And in that case we'll hit
> other problems as well I guess.

Yeah, this code looks a bit wrong.  My idea was to make absolutely sure that
we are back on the operating channel and have run the offchannel_return.
In that first bit of code that
does the hw_config(), I need to explicitly clear the scan-channel (and warn
if it is not already cleared).

>>   	/*
>>   	 * What if the nullfunc frames didn't arrive?
>> @@ -617,15 +635,13 @@ static void ieee80211_scan_state_enter_oper_channel(struct ieee80211_local *loca
>>   {
>>   	/* switch back to the operating channel */
>>   	local->scan_channel = NULL;
>> -	ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
>> +	if (!ieee80211_cfg_on_oper_channel(local))
>> +		ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
>>
>>   	/*
>> -	 * Only re-enable station mode interface now; beaconing will be
>> -	 * re-enabled once the full scan has been completed.
>> +	 * Re-enable vifs and beaconing.
>>   	 */
>> -	ieee80211_offchannel_return(local, false);
>> -
>> -	__clear_bit(SCAN_OFF_CHANNEL,&local->scanning);
>> +	ieee80211_offchannel_return(local, true);
>
> In cases where the qos latency is configured to something small
> we'll end up disabling/enabling beaconing for each scanned channel.
> However, as we'll stay at least 200ms on the operating channel
> it shouldn't hurt I guess.

That was my hope....

>
> All in all at least the changes to the scan code look reasonable to me.

Thanks for the review.  I'll work on the issues you brought up
and re-submit.

Thanks,
Ben

>
> Thanks,
> Helmut


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

      reply	other threads:[~2011-02-01 16:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-31 19:30 [PATCH v7] mac80211: Optimize scans on current operating channel greearb
2011-02-01 15:31 ` Helmut Schaa
2011-02-01 16:39   ` Ben Greear [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D483742.8030108@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=helmut.schaa@googlemail.com \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).