On Thu, Sep 27, 2012 at 2:31 AM, Eliad Peller <eliad@xxxxxxxxxx> wrote:
> On Thu, Sep 27, 2012 at 11:13 AM, Johannes Berg
> <johannes@xxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
