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
prev parent 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).