These add per-scan request controls for optional behaviours we've found
useful (they've been in Chrome OS for a long time). A patch for iw will
follow separately and the mods for wpa_supplicant are in our repo and
I'll push them to Jouni if these are accepted.
Sam Leffler (3):
{nl,cfg}80211: add a flags word to scan requests
mac80211: add support for tx to abort scan requests
cfg80211: add support for flushing old scan results
include/linux/nl80211.h | 19 +++++++++++++++++++
include/net/cfg80211.h | 17 +++++++++++++++++
net/mac80211/ieee80211_i.h | 2 ++
net/mac80211/scan.c | 19 ++++++++++++++++---
net/wireless/nl80211.c | 12 ++++++++++++
net/wireless/scan.c | 24 +++++++++++++++++++++---
net/wireless/sme.c | 1 +
7 files changed, 88 insertions(+), 6 deletions(-)
--
1.7.7.3
Thanks Sam for this patch series.
> These add per-scan request controls for optional behaviours we've found
> useful (they've been in Chrome OS for a long time). A patch for iw will
> follow separately and the mods for wpa_supplicant are in our repo and
> I'll push them to Jouni if these are accepted.
>
> Sam Leffler (3):
> {nl,cfg}80211: add a flags word to scan requests
> mac80211: add support for tx to abort scan requests
> cfg80211: add support for flushing old scan results
These patches do not apply cleanly against mac80211-next.git.
Amit will take over Sam's patches and respin a v2 series.
Thanks,
Bing
On Thu, Sep 27, 2012 at 2:13 AM, Johannes Berg
<[email protected]> wrote:
> On Tue, 2012-09-25 at 15:49 -0700, Sam Leffler wrote:
>> These add per-scan request controls for optional behaviours we've found
>> useful (they've been in Chrome OS for a long time). A patch for iw will
>> follow separately and the mods for wpa_supplicant are in our repo and
>> I'll push them to Jouni if these are accepted.
>>
>> Sam Leffler (3):
>> {nl,cfg}80211: add a flags word to scan requests
>> mac80211: add support for tx to abort scan requests
>> cfg80211: add support for flushing old scan results
>
> I like the flushing one, but I'm not so sure about the TX abort thing.
> How do you suggest to handle that when scanning is offloaded to the
> driver and/or firmware? Especially given that multi-channel is going to
> require a firmware implementation, I'm not sure how to achieve good
> behaviour across the different implementations.
>
> Maybe it'd be worthwhile to go for a more generic approach, marking
> scans as "low priority" or "high priority" or similar, and then
> implementing such behaviour based on such settings? Our device for
> example has a notion of "background scan" vs. "forced scan", which
> behave differently in the firmware, and it would be useful to be able to
> use these different behaviours. However, I can't say that "TX abort"
> would be a guaranteed scan behaviour for a "background scan".
Having a priority mechanism or similar would be fine. I usually
hesitate doing the generic thing because the actual semantics can very
so significantly from driver to driver that applications may end up
having to build in knowledge of which driver is being used to get what
they way want. But in fact what you suggest is how txabort is used--we
mark wpa_supplicant bgscan's w/ txabort while fgscan's are not marked
in this way.
>
> johannes
>
On Thu, Sep 27, 2012 at 2:31 AM, Eliad Peller <[email protected]> wrote:
> On Thu, Sep 27, 2012 at 11:13 AM, Johannes Berg
> <[email protected]> wrote:
>> On Tue, 2012-09-25 at 15:49 -0700, Sam Leffler wrote:
>>> These add per-scan request controls for optional behaviours we've found
>>> useful (they've been in Chrome OS for a long time). A patch for iw will
>>> follow separately and the mods for wpa_supplicant are in our repo and
>>> I'll push them to Jouni if these are accepted.
>>>
>>> Sam Leffler (3):
>>> {nl,cfg}80211: add a flags word to scan requests
>>> mac80211: add support for tx to abort scan requests
>>> cfg80211: add support for flushing old scan results
>>
>> I like the flushing one, but I'm not so sure about the TX abort thing.
>> How do you suggest to handle that when scanning is offloaded to the
>> driver and/or firmware? Especially given that multi-channel is going to
>> require a firmware implementation, I'm not sure how to achieve good
>> behaviour across the different implementations.
>>
>> Maybe it'd be worthwhile to go for a more generic approach, marking
>> scans as "low priority" or "high priority" or similar, and then
>> implementing such behaviour based on such settings? Our device for
>> example has a notion of "background scan" vs. "forced scan", which
>> behave differently in the firmware, and it would be useful to be able to
>> use these different behaviours. However, I can't say that "TX abort"
>> would be a guaranteed scan behaviour for a "background scan".
>>
> we also have some "urgency" option in our hw scan, but we currently
> never use it (not really sure when it should be used... maybe for
> roaming on beacon loss?)
>
> the TX abort is relevant mainly for sw scan.
> i'm not sure we really want to couple it with scan priority, though.
> otoh, userspace doesn't really care (or know) if we use sw or hw scan,
> so configuring it all with a single "scan priority" option does make
> sense.
>
> Eliad.
We found w/ ath9k that the mac80211 logic to defer channel changes
when there's been recent traffic was not enough to avoid noticeable
dips in long-running transfers (impacting the user experience)--hence
the txabort mechanism. As I've said elsewhere what we really want is
to distinguish bgscan from fgscan; if a generic mechanism is preferred
it would work for us.
-Sam
On Thu, Sep 27, 2012 at 11:13 AM, Johannes Berg
<[email protected]> wrote:
> On Tue, 2012-09-25 at 15:49 -0700, Sam Leffler wrote:
>> These add per-scan request controls for optional behaviours we've found
>> useful (they've been in Chrome OS for a long time). A patch for iw will
>> follow separately and the mods for wpa_supplicant are in our repo and
>> I'll push them to Jouni if these are accepted.
>>
>> Sam Leffler (3):
>> {nl,cfg}80211: add a flags word to scan requests
>> mac80211: add support for tx to abort scan requests
>> cfg80211: add support for flushing old scan results
>
> I like the flushing one, but I'm not so sure about the TX abort thing.
> How do you suggest to handle that when scanning is offloaded to the
> driver and/or firmware? Especially given that multi-channel is going to
> require a firmware implementation, I'm not sure how to achieve good
> behaviour across the different implementations.
>
> Maybe it'd be worthwhile to go for a more generic approach, marking
> scans as "low priority" or "high priority" or similar, and then
> implementing such behaviour based on such settings? Our device for
> example has a notion of "background scan" vs. "forced scan", which
> behave differently in the firmware, and it would be useful to be able to
> use these different behaviours. However, I can't say that "TX abort"
> would be a guaranteed scan behaviour for a "background scan".
>
we also have some "urgency" option in our hw scan, but we currently
never use it (not really sure when it should be used... maybe for
roaming on beacon loss?)
the TX abort is relevant mainly for sw scan.
i'm not sure we really want to couple it with scan priority, though.
otoh, userspace doesn't really care (or know) if we use sw or hw scan,
so configuring it all with a single "scan priority" option does make
sense.
Eliad.
On Fri, Sep 28, 2012 at 3:57 AM, Johannes Berg
<[email protected]> wrote:
> On Thu, 2012-09-27 at 09:39 -0700, Sam Leffler wrote:
>
>> > Maybe it'd be worthwhile to go for a more generic approach, marking
>> > scans as "low priority" or "high priority" or similar, and then
>> > implementing such behaviour based on such settings? Our device for
>> > example has a notion of "background scan" vs. "forced scan", which
>> > behave differently in the firmware, and it would be useful to be able to
>> > use these different behaviours. However, I can't say that "TX abort"
>> > would be a guaranteed scan behaviour for a "background scan".
>>
>> Having a priority mechanism or similar would be fine. I usually
>> hesitate doing the generic thing because the actual semantics can very
>> so significantly from driver to driver that applications may end up
>> having to build in knowledge of which driver is being used to get what
>> they way want. But in fact what you suggest is how txabort is used--we
>> mark wpa_supplicant bgscan's w/ txabort while fgscan's are not marked
>> in this way.
>
> Yes, I agree it's a slippery slope, however with all the different
> mechanisms that can be built in drivers/firmware/... I'm not really sure
> how else to treat them?
>
> In theory we could say that we have
> * TX abort
> * Intel BG scan (otherwise opaque, in firmware)
> * TI BG scan (otherwise opaque, in firmware)
> * ...
>
> as separate flags/settings/..., but ultimately it seems that all that
> would happen is that everybody would patch the supplicant to use their
> mechanism for background scanning if available. Then, in theory, the
> supplicant would know which one it's using, but since it doesn't really
> know the semantics it doesn't really make a difference?
>
> Maybe we should agree on a few basic rules for the "generic" BG scan,
> but I'm not sure what sensible rules would be. They can't be rules on
> reliability, as then "tx-abort" wouldn't be a valid implementation
> (unless you retried, but that could literally run forever), and I'm not
> sure what other kind of rule would make sense. Either way, the
> supplicant is going to have to assume that a finished "BG scan" has a
> smaller result set than a "regular" scan ...
>
> There might be value in having more information about the actual "abort
> due to TX" (whether it happened or not), but again that would be tied to
> the specific implementation, and I'm not sure how to formulate any such
> thing more generically. Right now, I don't even know how our or TI's
> implementation behaves differently for the different types of scan.
In my experience the reason why a bgscan was aborted is not important;
you just want to know true/false so you know if you have a "complete
picture" of the environment to make decisions. I also find the abort
model much preferable to extending the scan work because unless
results are sent back immediately you can easily end up sending back
stale results.
-Sam
On Thu, 2012-09-27 at 09:39 -0700, Sam Leffler wrote:
> > Maybe it'd be worthwhile to go for a more generic approach, marking
> > scans as "low priority" or "high priority" or similar, and then
> > implementing such behaviour based on such settings? Our device for
> > example has a notion of "background scan" vs. "forced scan", which
> > behave differently in the firmware, and it would be useful to be able to
> > use these different behaviours. However, I can't say that "TX abort"
> > would be a guaranteed scan behaviour for a "background scan".
>
> Having a priority mechanism or similar would be fine. I usually
> hesitate doing the generic thing because the actual semantics can very
> so significantly from driver to driver that applications may end up
> having to build in knowledge of which driver is being used to get what
> they way want. But in fact what you suggest is how txabort is used--we
> mark wpa_supplicant bgscan's w/ txabort while fgscan's are not marked
> in this way.
Yes, I agree it's a slippery slope, however with all the different
mechanisms that can be built in drivers/firmware/... I'm not really sure
how else to treat them?
In theory we could say that we have
* TX abort
* Intel BG scan (otherwise opaque, in firmware)
* TI BG scan (otherwise opaque, in firmware)
* ...
as separate flags/settings/..., but ultimately it seems that all that
would happen is that everybody would patch the supplicant to use their
mechanism for background scanning if available. Then, in theory, the
supplicant would know which one it's using, but since it doesn't really
know the semantics it doesn't really make a difference?
Maybe we should agree on a few basic rules for the "generic" BG scan,
but I'm not sure what sensible rules would be. They can't be rules on
reliability, as then "tx-abort" wouldn't be a valid implementation
(unless you retried, but that could literally run forever), and I'm not
sure what other kind of rule would make sense. Either way, the
supplicant is going to have to assume that a finished "BG scan" has a
smaller result set than a "regular" scan ...
There might be value in having more information about the actual "abort
due to TX" (whether it happened or not), but again that would be tied to
the specific implementation, and I'm not sure how to formulate any such
thing more generically. Right now, I don't even know how our or TI's
implementation behaves differently for the different types of scan.
johannes
On Thu, Sep 27, 2012 at 11:31 AM, Eliad Peller <[email protected]> wrote:
> On Thu, Sep 27, 2012 at 11:13 AM, Johannes Berg
> <[email protected]> wrote:
>> On Tue, 2012-09-25 at 15:49 -0700, Sam Leffler wrote:
>>> These add per-scan request controls for optional behaviours we've found
>>> useful (they've been in Chrome OS for a long time). A patch for iw will
>>> follow separately and the mods for wpa_supplicant are in our repo and
>>> I'll push them to Jouni if these are accepted.
>>>
>>> Sam Leffler (3):
>>> {nl,cfg}80211: add a flags word to scan requests
>>> mac80211: add support for tx to abort scan requests
>>> cfg80211: add support for flushing old scan results
>>
>> I like the flushing one, but I'm not so sure about the TX abort thing.
>> How do you suggest to handle that when scanning is offloaded to the
>> driver and/or firmware? Especially given that multi-channel is going to
>> require a firmware implementation, I'm not sure how to achieve good
>> behaviour across the different implementations.
>>
>> Maybe it'd be worthwhile to go for a more generic approach, marking
>> scans as "low priority" or "high priority" or similar, and then
>> implementing such behaviour based on such settings? Our device for
>> example has a notion of "background scan" vs. "forced scan", which
>> behave differently in the firmware, and it would be useful to be able to
>> use these different behaviours. However, I can't say that "TX abort"
>> would be a guaranteed scan behaviour for a "background scan".
>>
> we also have some "urgency" option in our hw scan, but we currently
> never use it (not really sure when it should be used... maybe for
> roaming on beacon loss?)
>
> the TX abort is relevant mainly for sw scan.
> i'm not sure we really want to couple it with scan priority, though.
> otoh, userspace doesn't really care (or know) if we use sw or hw scan,
> so configuring it all with a single "scan priority" option does make
> sense.
I think the wl12xx FW does something similar with Tx during scan
automatically - it makes the scan last longer, and hops on the Tx
channel so packets get sent. So at least their intended use-case we
have covered.
On Tue, 2012-09-25 at 15:49 -0700, Sam Leffler wrote:
> These add per-scan request controls for optional behaviours we've found
> useful (they've been in Chrome OS for a long time). A patch for iw will
> follow separately and the mods for wpa_supplicant are in our repo and
> I'll push them to Jouni if these are accepted.
>
> Sam Leffler (3):
> {nl,cfg}80211: add a flags word to scan requests
> mac80211: add support for tx to abort scan requests
> cfg80211: add support for flushing old scan results
I like the flushing one, but I'm not so sure about the TX abort thing.
How do you suggest to handle that when scanning is offloaded to the
driver and/or firmware? Especially given that multi-channel is going to
require a firmware implementation, I'm not sure how to achieve good
behaviour across the different implementations.
Maybe it'd be worthwhile to go for a more generic approach, marking
scans as "low priority" or "high priority" or similar, and then
implementing such behaviour based on such settings? Our device for
example has a notion of "background scan" vs. "forced scan", which
behave differently in the firmware, and it would be useful to be able to
use these different behaviours. However, I can't say that "TX abort"
would be a guaranteed scan behaviour for a "background scan".
johannes