Re: [PATCH 1/2] [RFC] cfg80211: configuration of Bluetooth coexistence mode

[Johannes Berg <johannes@sipsolutions.net>]

On Wed, 2013-02-27 at 11:27 +0100, Dan Williams wrote:
> 
> We also don't know what IP configuration method will get used; whether
> it will be IPv6 RA, DHCPv4 or DHCPv6, IPv4 autoconf, or static.  Only
> the connection manager knows that.  Only the connection manager/DHCP
> client know when they expect a lease renew operation to start too.
> wpa_supplicant doesn't know any of these things either since it doesn't
> do anything IP related.

Right, and if it's static you don't want any of this. I don't think
network latency stuff is a good method, even though on the face of it
the idea here is to reduce the initial connection latency.

> I think the best approach here is to allow the higher layers to hint to
> the driver that some operations that are about to start must be "more
> reliable".  That includes EAPOL, DHCP, IP autoconfiguration, etc.  Then
> when the higher layers know the operation is finished, they can indicate
> the operations are done and the driver can go do whatever it wants.

Yeah, I agree.

Note that it's less about being "more reliable" and more about being
"fast" (for some definition of that), in particular in the multi-channel
scenario you'd want to attempt to not switch away from the channel (if
possible) until DHCP finishes, or at least give it a chance to finish
quickly. But for example for static IP configuration you don't need to
and don't necessarily want to block being on that channel just in case
DHCP happens. Similarly with BT Coex of course, though there I guess
it's more about priority.

In any case it's about completing the connection to the network quickly
before being forced to go to powersave. In particular IPv6 might also
require multicast so doing powersave there really hurts (DTIM beacon.)

> The driver/stack may wish to do any of [set 1Mb rate, block rate
> control, change BT coex, turn on microwave protection, whatever] and
> that's great, the upper layers don't care about what the driver does,
> just that the reliability of the operation is preserved.

I'd say "reliability of the operation is _increased_" I guess :-) But
yeah.

johannes