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

["Arend van Spriel" <arend@broadcom.com>]

On 02/27/13 11:27, Dan Williams wrote:
> On Mon, 2013-02-25 at 14:07 +0100, Felix Fietkau wrote:
>> On 2013-02-25 11:25 AM, Johannes Berg wrote:
>>> On Mon, 2013-02-25 at 06:54 +0100, Felix Fietkau wrote:
>>>
>>>> Most devices have some kind of connection manager that has a high-level
>>>> perspective of when it's fully connected (which includes DHCP/bootp).
>>>> Why not just let that connection manager set a sane maximum network
>>>> latency value via pm_qos network_latency and derive btcoex weight
>>>> changing and multi-channel settings from that?
>>>
>>> Frankly, I don't think that's going to work well. We tried using the
>>> pm_qos framework once and nothing ever used it. Android isn't going to
>>> change to it, so we'd be stuck with hacks like setting pm_qos in
>>> wpa_supplicant which is just as awkward.
>> If only the connection manager gets changed to use it, that would
>> already be enough. It doesn't have to be pushed into dhcp clients and
>> other applications.
>>
>>> Also, what you mostly want isn't really so much a weight but rather a
>>> time-based approach to give it high priority until the connection
>>> handshake completes (we already do for auth/assoc/... until authorized)
>>> so I think using the pm_qos framework to give priority wouldn't work
>>> very well since there'd also be no way to tell when it was "done"
>> Just release the latency requirement in the connection manager once the
>> handshake is done. It knows...
>
> 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.
>
> 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.

Indeed the RFC approach was explicit about the scope of this interface 
being BT coex or actually BT coex override. Johannes proposes one 
dedicated to DHCP as a similar interface in Android is used for that 
right now. Abstracting it to "more reliable" mainly avoids renaming it 
when someone comes up with a use-case other than BT coex or DHCP.

> 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.

It is actually the reliability of the connection, but it may depend on 
what you mean by "operation" here. I think from user-space perpective 
this API is at most a notification to the driver, which *may* result in 
a more reliable protocol exchange in terms of reliability and/or latency.

Regards,
Arend