All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC 0/3] mac80211 scanning restructuring
Date: Fri, 06 Jul 2012 14:45:16 -0700	[thread overview]
Message-ID: <4FF75C6C.9030108@candelatech.com> (raw)
In-Reply-To: <1341610508.16893.26.camel@jlt3.sipsolutions.net>

On 07/06/2012 02:35 PM, Johannes Berg wrote:
> On Fri, 2012-07-06 at 14:30 -0700, Ben Greear wrote:
>> On 07/06/2012 02:05 PM, Johannes Berg wrote:
>>> I decided that with multi-channel coming and thus us using more
>>> virtual interfaces, the scanning code was going to be the first
>>> victim of some factoring ;-)
>>>
>>> Please review. The only thing that isn't quite clear to me is
>>> whether or not I can really remove the channel == oper_channel
>>> check, but it's only applied to probe resp/beacon frames so it
>>> seems a bit pointless to try to keep it?
>>
>> For what it's worth, I don't see any problems with the patches.
>
> :-)
> I think you should see much fewer calls to cfg80211 with this when
> beacons are received, when you have many virtual interfaces, but I'm not
> sure how you'd see that unless you carefully measure CPU utilization.
>
>> Another enhancement I was thinking about would be to allow
>> vifs to piggy-back on other vif's scans.  Instead of
>> returning EBUSY when another vif is already scanning, just
>> register to receive the scanning vif's results when it finishes.
>
> Hmm, yes, technically that's possible. However, you'd have to verify
> that it used exactly the same scan parameters, which seems like a lot of
> overhead? Given that we give you the scan parameters in the nl80211
> event when the scan finishes (at least I think we do), you could even do
> this optimisation in userspace, when -EBUSY is returned?

I was thinking to only enable the wait-for-peer-scan logic if
peer and requested scans are 'normal', or some simple subset of
mostly-normal that is easy to check for.  It would still always
be valid to return EBUSY if you cannot obviously share scan results.

Main issue that I see is that if one interface is constantly scanning
in wpa_supplicant because it can't find what it's looking for,
you can often get a failure if you manually run 'iw scan'
on the command line, and that is exactly when you often DO want
to see some manual scan results :)

I've already optimized wpa_supplicant to share scans in user-space
some time back (and code has been upstream for a while), and that is
a big help..but doesn't help non-supplicant programs.

Thanks,
Ben

>
> johannes
>


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




      reply	other threads:[~2012-07-06 21:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-06 21:05 [RFC 0/3] mac80211 scanning restructuring Johannes Berg
2012-07-06 21:05 ` [RFC 1/3] mac80211: make scan_sdata pointer usable with RCU Johannes Berg
2012-07-08 16:27   ` Arik Nemtsov
2012-07-09  7:59     ` Johannes Berg
2012-07-09  8:48       ` Arik Nemtsov
2012-07-09  9:10         ` Johannes Berg
2012-07-09  9:15           ` Arik Nemtsov
2012-07-09  9:23             ` Johannes Berg
2012-07-09  9:39               ` Arik Nemtsov
2012-07-09  9:43                 ` Johannes Berg
2012-07-09  9:53                   ` Arik Nemtsov
2012-07-06 21:05 ` [RFC 2/3] mac80211: track scheduled scan virtual interface Johannes Berg
2012-07-06 21:05 ` [RFC 3/3] mac80211: redesign scan RX Johannes Berg
2012-07-07 22:39   ` Eliad Peller
2012-07-08  9:28     ` Johannes Berg
2012-07-06 21:30 ` [RFC 0/3] mac80211 scanning restructuring Ben Greear
2012-07-06 21:35   ` Johannes Berg
2012-07-06 21:45     ` 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=4FF75C6C.9030108@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=johannes@sipsolutions.net \
    --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 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.