| Message ID | 1375087158-22077-2-git-send-email-michal.kazior@tieto.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Mon, 2013-07-29 at 10:39 +0200, Michal Kazior wrote: > + * @NL80211_ATTR_SCAN_CHAN_TIME: Specifies how many msec should a driver spend > + * on each channel during scanning. This is optional and the default is > + * leave the decision up to the driver. This setting may, but preferrably typo: preferably :) > + * shouldn't, be ignored by driver. This seems a bit iffy - you don't differentiate between active/passive scans? Also maybe there should be a bit saying "I support scan timing" or even the min/max times? This also interferes a bit with some other scan optimisations that could be done at a low firmware level, so I think we should be careful and actually say that this is really more intended for measurement use cases and not for normal scans? Or maybe we should have a separate measurement command with similar semantics? This all doesn't seem very clear to me yet :) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 1 August 2013 09:40, Johannes Berg <johannes@sipsolutions.net> wrote: > On Mon, 2013-07-29 at 10:39 +0200, Michal Kazior wrote: > >> + * @NL80211_ATTR_SCAN_CHAN_TIME: Specifies how many msec should a driver spend >> + * on each channel during scanning. This is optional and the default is >> + * leave the decision up to the driver. This setting may, but preferrably > > typo: preferably :) > >> + * shouldn't, be ignored by driver. > > This seems a bit iffy - you don't differentiate between active/passive > scans? Is there a reason this should be differentiated? > Also maybe there should be a bit saying "I support scan timing" or even > the min/max times? Sounds good. I can add it. > This also interferes a bit with some other scan optimisations that could > be done at a low firmware level, so I think we should be careful and > actually say that this is really more intended for measurement use cases > and not for normal scans? > > Or maybe we should have a separate measurement command with similar > semantics? This all doesn't seem very clear to me yet :) Motivation behind this patchset is to simplify ACS implementation and depend on scan. This also allows easier fallback from survey-based ACS to BSS-based one. Other use cases are a side-effect so perhaps clarifying the intent in the docs is enough. Pozdrawiam / Best regards, Micha? Kazior. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2013-08-01 at 11:14 +0200, Michal Kazior wrote: > > This seems a bit iffy - you don't differentiate between active/passive > > scans? > > Is there a reason this should be differentiated? Well they don't usually have the same timing, passive channel dwell time usually needs to be longer than on active channels. > > This also interferes a bit with some other scan optimisations that could > > be done at a low firmware level, so I think we should be careful and > > actually say that this is really more intended for measurement use cases > > and not for normal scans? > > > > Or maybe we should have a separate measurement command with similar > > semantics? This all doesn't seem very clear to me yet :) > > Motivation behind this patchset is to simplify ACS implementation and > depend on scan. This also allows easier fallback from survey-based ACS > to BSS-based one. Sure, I understand. > Other use cases are a side-effect so perhaps clarifying the intent in > the docs is enough. I'm just saying that this is a fundamentally different usage than actual scanning. Let's say for the sake of the argument I find a way to scan channels quicker and implement that in my device (hw_scan). I don't think this is too far-fetched, imagine I have an 80MHz capable device and can send probe request 4x transmissions on all the subchannels, if somehow I manage to separate the receive then I could scan 4x as quickly. I don't think this particular thing is possible but I could imagine scan optimisations like it. Now this comes along - and suddenly the API requires that you stay on each specified channel for the given period of time. Any such "non-traditional" scan optimisations would have to be given up, so in a sense this fundamentally alters the semantics of the scan primitive, where before it was "give me the list of networks (with these SSIDs) on these channels" it now becomes "go to each channel, stay there for this amount of time and ..." That's what I'm worried about - the implicit semantic change here. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2 August 2013 13:25, Johannes Berg <johannes@sipsolutions.net> wrote: > On Thu, 2013-08-01 at 11:14 +0200, Michal Kazior wrote: > >> > This seems a bit iffy - you don't differentiate between active/passive >> > scans? >> >> Is there a reason this should be differentiated? > > Well they don't usually have the same timing, passive channel dwell time > usually needs to be longer than on active channels. > >> > This also interferes a bit with some other scan optimisations that could >> > be done at a low firmware level, so I think we should be careful and >> > actually say that this is really more intended for measurement use cases >> > and not for normal scans? >> > >> > Or maybe we should have a separate measurement command with similar >> > semantics? This all doesn't seem very clear to me yet :) >> >> Motivation behind this patchset is to simplify ACS implementation and >> depend on scan. This also allows easier fallback from survey-based ACS >> to BSS-based one. > > Sure, I understand. > >> Other use cases are a side-effect so perhaps clarifying the intent in >> the docs is enough. > > I'm just saying that this is a fundamentally different usage than actual > scanning. Let's say for the sake of the argument I find a way to scan > channels quicker and implement that in my device (hw_scan). I don't > think this is too far-fetched, imagine I have an 80MHz capable device > and can send probe request 4x transmissions on all the subchannels, if > somehow I manage to separate the receive then I could scan 4x as > quickly. I don't think this particular thing is possible but I could > imagine scan optimisations like it. > > Now this comes along - and suddenly the API requires that you stay on > each specified channel for the given period of time. Any such > "non-traditional" scan optimisations would have to be given up, so in a > sense this fundamentally alters the semantics of the scan primitive, > where before it was "give me the list of networks (with these SSIDs) on > these channels" it now becomes "go to each channel, stay there for this > amount of time and ..." > > That's what I'm worried about - the implicit semantic change here. I think I understand your point now. I'm thinking of using series of passive scans for ACS now, so perhaps the whole chan_time stuff is unnecessary. What are your thoughts about it? Pozdrawiam / Best regards, Micha? Kazior. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Johannes and Michal , In this context I would also like to mention that there are also some use cases ( Ex WiFi Positioning) , where good performance shall result from using signals from as many Access Points as possible, a fixed dwell / chan time in the host driver shall result in the poor discovery efficiency of the Access Points,negatively impacting WiFi positioning performance. I would say such applications shall benefit by configuring a chan (dwell)_time. Also,an attribute corresponding to the mode of the scan ( active / passive ) , along with chan_time would benefit such applications with more configurable options. Isn't it ? Please correct me . Regards, Sunil On Fri, Aug 2, 2013 at 6:00 PM, Sunil Dutt <usdutt@gmail.com> wrote: > Hi Johannes and Michal , > In this context I would also like to mention that there are also some use > cases ( Ex WiFi Positioning) , where good performance shall result from > using signals from as many Access Points as possible, a fixed dwell / chan > time in the host driver shall result in the poor discovery efficiency of the > Access Points,negatively impacting WiFi positioning performance. > > I would say such applications shall benefit by configuring a chan > (dwell)_time. > Also,an attribute corresponding to the mode of the scan ( active / passive ) > , along with chan_time would benefit such applications with more > configurable options. Isn't it ? > Please correct me . > > Regards, > Sunil > > > > > On Fri, Aug 2, 2013 at 4:55 PM, Johannes Berg <johannes@sipsolutions.net> > wrote: >> >> On Thu, 2013-08-01 at 11:14 +0200, Michal Kazior wrote: >> >> > > This seems a bit iffy - you don't differentiate between active/passive >> > > scans? >> > >> > Is there a reason this should be differentiated? >> >> Well they don't usually have the same timing, passive channel dwell time >> usually needs to be longer than on active channels. >> >> > > This also interferes a bit with some other scan optimisations that >> > > could >> > > be done at a low firmware level, so I think we should be careful and >> > > actually say that this is really more intended for measurement use >> > > cases >> > > and not for normal scans? >> > > >> > > Or maybe we should have a separate measurement command with similar >> > > semantics? This all doesn't seem very clear to me yet :) >> > >> > Motivation behind this patchset is to simplify ACS implementation and >> > depend on scan. This also allows easier fallback from survey-based ACS >> > to BSS-based one. >> >> Sure, I understand. >> >> > Other use cases are a side-effect so perhaps clarifying the intent in >> > the docs is enough. >> >> I'm just saying that this is a fundamentally different usage than actual >> scanning. Let's say for the sake of the argument I find a way to scan >> channels quicker and implement that in my device (hw_scan). I don't >> think this is too far-fetched, imagine I have an 80MHz capable device >> and can send probe request 4x transmissions on all the subchannels, if >> somehow I manage to separate the receive then I could scan 4x as >> quickly. I don't think this particular thing is possible but I could >> imagine scan optimisations like it. >> >> Now this comes along - and suddenly the API requires that you stay on >> each specified channel for the given period of time. Any such >> "non-traditional" scan optimisations would have to be given up, so in a >> sense this fundamentally alters the semantics of the scan primitive, >> where before it was "give me the list of networks (with these SSIDs) on >> these channels" it now becomes "go to each channel, stay there for this >> amount of time and ..." >> >> That's what I'm worried about - the implicit semantic change here. >> >> johannes >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-wireless" >> in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > That's what I'm worried about - the implicit semantic change here. > > I think I understand your point now. > > I'm thinking of using series of passive scans for ACS now, so perhaps > the whole chan_time stuff is unnecessary. What are your thoughts about > it? Well, still then you're relying on the fact that passive channels scans will stick to each channel for ~110ms or so. This is true today, but it's not really specified. I don't think that using the scan command would be a big deal, but maybe this 'measurement' behaviour should be explicitly enabled? Maybe other devices even have to do something special to collect the data. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index aeaf6df..2d46112 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -1323,6 +1323,8 @@ struct cfg80211_ssid { * @aborted: (internal) scan request was notified as aborted * @notified: (internal) scan request was notified as done or aborted * @no_cck: used to send probe requests at non CCK rate in 2GHz band + * @chan_time: how many msec driver should stay on each channel during scan. + * Setting 0 leaves the decision up to the driver. */ struct cfg80211_scan_request { struct cfg80211_ssid *ssids; @@ -1332,6 +1334,7 @@ struct cfg80211_scan_request { const u8 *ie; size_t ie_len; u32 flags; + int chan_time; u32 rates[IEEE80211_NUM_BANDS]; diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h index eb68735..4ea1d9b 100644 --- a/include/uapi/linux/nl80211.h +++ b/include/uapi/linux/nl80211.h @@ -1469,6 +1469,11 @@ enum nl80211_commands { * * @NL80211_ATTR_COALESCE_RULE: Coalesce rule information. * + * @NL80211_ATTR_SCAN_CHAN_TIME: Specifies how many msec should a driver spend + * on each channel during scanning. This is optional and the default is + * leave the decision up to the driver. This setting may, but preferrably + * shouldn't, be ignored by driver. + * * @NL80211_ATTR_MAX: highest attribute number currently defined * @__NL80211_ATTR_AFTER_LAST: internal use */ @@ -1771,6 +1776,8 @@ enum nl80211_attrs { NL80211_ATTR_COALESCE_RULE, + NL80211_ATTR_SCAN_CHAN_TIME, + /* add attributes here, update the policy in nl80211.c */ __NL80211_ATTR_AFTER_LAST, diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index 03d4ef9..27a8fef 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -5298,6 +5298,10 @@ static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info) request->no_cck = nla_get_flag(info->attrs[NL80211_ATTR_TX_NO_CCK_RATE]); + if (info->attrs[NL80211_ATTR_SCAN_CHAN_TIME]) + request->chan_time = + nla_get_u32(info->attrs[NL80211_ATTR_SCAN_CHAN_TIME]); + request->wdev = wdev; request->wiphy = &rdev->wiphy; request->scan_start = jiffies;
The new scan parameter allows user to specify how long driver should remain on each scanned channel. The default is to leave it up to driver to decide. If specified it is preferred for driver to respect this setting although it may ignore it if it can't support it. This can be useful to do very quick/slow scans and/or gether survey data, e.g. for automatic channel selection. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> --- include/net/cfg80211.h | 3 +++ include/uapi/linux/nl80211.h | 7 +++++++ net/wireless/nl80211.c | 4 ++++ 3 files changed, 14 insertions(+)