RE: [RFC] nl80211: Added NL80211 commands for Bluetooth-WiFi coex

[Marcel Holtmann <marcel@holtmann.org>]

Hi Suraj,

> > this looks like the total wrong approach to me. This needs to be done between mac80211 and Bluetooth subsystems in the kernel directly. Going through userspace for this is a pretty bad idea.
> 
> > Especially if you wanna listen on D-Bus events from bluetoothd and then run another process to then execute nl80211 commands looks like total overhead at no gain. Not to talk about potential latency > effects that might be counterproductive.
> 
> > What you really want is a way to mark A2DP channels for streaming from userspace as streaming/realtime/priority so the Bluetooth subsystem knows on what to do with it and that way can also tell > > mac80211 correctly about coex settings.
> 
> > We are already settings flushable flags for A2DP streaming channels and there is work ongoing for SO_PRIORITY support with L2CAP sockets.
> 
> More than the A2DP connection, it would be more useful to find out when A2DP start/stop streaming so that we can know when to reallocate resource to Bluetooth. Is it possible to tap this information out of the Bluetooth core?
> Also, can you suggest a way to get A2DP streaming status, inquiry status, and SCO and ACL role without a hack in the Bluetooth subsystem?

the inquiry status is tracked by the Linux kernel since ever. Same goes
for ACL and SCO status. The kernel keeps track over almost everything on
the HCI level and will do proper cleanup afterwards. Doing this in
userspace will not work out. And it is also racy.

Especially in the future bluetoothd will be tracking less and less
information. The new management interface will hide almost every single
state from bluetoothd where the kernel is doing the job anyway and can
do a way better job in the first place. This is also leads to power
consumption advantages since bluetoothd does not need to be woken up
that often anyway. And in addition the kernel has not deal with the
extra HCI filter handling.

The only thing that you mentioned here is A2DP streaming. And by the
nature of the A2DP protocol, you do establish a second L2CAP channel
that is just used for streaming. That channel is also only present if
you are streaming right now. If not streaming is going on, it will be
disconnected. So it is pretty easy to have bluetoothd tag such a channel
with proper SO_PRIORITY (once we have that code merged upstream) and
then the Bluetooth subsystem knows when A2DP streaming or any high
priority/realtime data is transferred over Bluetooth.

Regards

Marcel