Re: [RFC V3] cfg80211: introduce critical protocol indication from user-space

[Ben Greear <greearb@candelatech.com>]

On 04/02/2013 07:04 AM, Arend van Spriel wrote:
> Some protocols need a more reliable connection to complete
> successful in reasonable time. This patch adds a user-space
> API to indicate the wireless driver that a critical protocol
> is about to commence and when it is done, using nl80211 primitives
> NL80211_CMD_CRIT_PROTOCOL_START and NL80211_CRIT_PROTOCOL_STOP.
>
> The driver can support this by implementing the cfg80211 callbacks
> .crit_proto_start() and .crit_proto_stop(). Examples of protocols
> that can benefit from this are DHCP, EAPOL, APIPA. Exactly how the
> link can/should be made more reliable is up to the driver. Things
> to consider are avoid scanning, no multi-channel operations, and
> alter coexistence schemes.
>
> Cc: Ben Greear <greearb@candelatech.com>
> Cc: Dan Williams <dcbw@redhat.com>
> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
> Signed-off-by: Arend van Spriel <arend@broadcom.com>
> ---
> Here is version 3. I tried to deal with all the review comments
> I received, except for the one below:
>
> Ben Greear said: "
> Also, you would probably need to enforce in the kernel that only
> x out of y time in any given period can be locked, otherwise lots
> of different dhclient processes (perhaps erroneously spawned..or
> running on lots of different VIFs) could basically disable scanning
> or channel changes..."
>
> Not sure how or even if we should deal with this. Any thoughts?

I think you could treat the start-critical-section as requests that may be
silently (or otherwise) ignored by the driver.

At a minimum, you could keep a timestamp of the last 'stop' time, and
ignore any requests that come in too soon after that stop.

Or to be more clever, keep last 5 or so start/stop times and
make sure the system is on average available for non-critical
stuff at least XX% of the time.

I can imagine wanting to support this in ath9k (or mac80211)
with lots of virtual interfaces, and in this case we would
definitely need some constraints to keep the system from constantly
being in critical section.  I guess this could be a driver
issue, however...NICs that support only a single interface may
not care about this...

Thanks,
Ben


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