> -----Original Message----- > From: Luiz Augusto von Dentz [mailto:luiz.dentz@xxxxxxxxx] > Sent: Monday, August 15, 2011 10:53 AM > To: Marcel Holtmann > Cc: ilia.kolominsky@xxxxxxxxx; linux-bluetooth@xxxxxxxxxxxxxxx; Ilia, > Kolominsky > Subject: Re: [PATCH v2 bluetooth-next] Added ioctl flow specification > command on HCI socket > > Hi Marcel, > > On Mon, Aug 15, 2011 at 12:17 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> > wrote: > > Hi Ilia, > > > >> While it is possible to send flow specification HCI command > >> from the user space directly via the send api of HCI socket, > >> a more specific approach is preferable over the opaque > >> HCI command, since it will allow for centralized mangament of > >> flow specifiaction requests for different l2cap flows over > >> the same acl link in future. This feature was used successfully > >> for solving the qos A2DP issue in piconet with concurent file > >> transfer. > >> > >> Signed-off-by: Ilia Kolomisnky <iliak@xxxxxx> > >> --- > >> include/net/bluetooth/hci.h | 38 ++++++++++++++++++---- > >> include/net/bluetooth/hci_core.h | 3 ++ > >> net/bluetooth/hci_conn.c | 1 + > >> net/bluetooth/hci_core.c | 63 > ++++++++++++++++++++++++++++++++++++++ > >> net/bluetooth/hci_event.c | 37 ++++++++++++++++++++++ > >> net/bluetooth/hci_sock.c | 2 + > >> 6 files changed, 137 insertions(+), 7 deletions(-) > >> > >> diff --git a/include/net/bluetooth/hci.h > b/include/net/bluetooth/hci.h > >> index be30aab..f0f90d5 100644 > >> --- a/include/net/bluetooth/hci.h > >> +++ b/include/net/bluetooth/hci.h > >> @@ -109,6 +109,8 @@ enum { > >> #define HCISETLINKMODE _IOW('H', 226, int) > >> #define HCISETACLMTU _IOW('H', 227, int) > >> #define HCISETSCOMTU _IOW('H', 228, int) > >> +#define HCISETFLOWSPEC _IOW('H', 229, int) > >> + > > > > I am not accepting any new addition of ioctl() at this moment. We are > > moving towards a proper defined management API. And that is how this > > should be addressed. >From what I see in mgmt.h, I cant draw a fine conceptual line between the qos/tm features and the functionality that is defined there currently - for instance stuff like MGMT_OP_SET_DISCOVERABLE and MGMT_OP_SET_CONNECTABLE. On the other hand I completely agree that the qos issues should be managed in a conceptually central component. The bottom line, I am saying that given the complexity level of the qos management ( that I describe bellow ) it may be appropriate to introduce separate traffic management component. > > > > And these kind of ictol() that have to execute a HCI command and wait > > for the result are not a good for being an ioctl() in the first > place. > > > > Regards > > > > Marcel > > I got the impression that the spec indicates this should first be > negotiated on l2cap level since there is a command with exact same > parameters, perhaps the way to go would be to have this as a socket > option and require some capability to be able to set them, after the > L2CAP QoS negotiation completes the kernel could automatically set the > HCI QoS based on that. > > -- > Luiz Augusto von Dentz I actually tried to keep it simple with this patch despite the fact that IMHO qos issues that exist in Bluetooth require a more substantial effort. But since the patch is not accepted and based on Luiz's comments (that note the complexity of the issue anyway) I take the opportunity to RFC a more serious solution for battling the bluetooth qos issues. First of all, the description of 2 qos problems that we experience (there may exist more of course): 1. Piconet ACL coexistence: HeadSet <--- ACL/A2DP/AVRCP ---> Master <---- ACL/OBEX ----> Slave B In this scenario user audio experience is unacceptable, since transport service does not provide the requested throughput, because the radio is shared with Slave B. This issue was addressed successfully with this patch and modifications to the user-space which used the ioctl during AVDTP configuration stage. In short, the master's link manager provided the required bandwidth for the A2DP stream. 2. L2CAP coexistence: CarKit <---ACL/2A2DP/AVRCP/BPAP---> Phone In this scenario user audio experience is also unsatisfying, but not due to the link manager, but due to the l2cap. Thus, solution that worked in (1) won`t help here. The need for traffic management in l2cap is obvious. So, academically speaking, we have 2 levels of output queues that need to be managed accordingly to required qos. I propose the following hi-level design (that draws on network stack scheduler): l2cap_1------> l2cap_qsched----------> baseband_qsched l2cap_2-----^ ^ ^ | | Flow classifications HCI_FLOW_SPEC commands ^ | | | | BT traffic manager ---------------- ^ | | User space control l2cap_qsched - manages outgoing queues according to flow classifications db. baseband_qsched - implemented on the controller, controlled with HCI_FLOW_SPEC commands. Flow classifications - db that contains flow classifications and qos specs. BT traffic manager - manages the db, sends HCI_FLOW_SPEC commands, ensures coherency of qos settings on both levels. E.g.: l2cap_1 is A2DP stream, requests X KB/s throughput, l2cap_2 is AVRCP, requests 100ms delay. Both are over the same ACL link, thus, the BT traffic manager should be able to calculate the baseband_qsched requirements for that particular ACL correctly. The manager also needs to "sense" the termination of l2cap flows in order to update the baseband_qsched settings accordingly. OPEN ISSUE: How to handle l2cap qos negotiation procedures. User space control - API for controlling BT traffic management. Probably commands like "Add/Remove classifications". Probably, extensions to the current management interface or another form of user-space access. User space control app may look like this: "bt_tc add -p A2DP -b 160" - request 160KB/s throughput for A2DP The main question here - is there a chance that something like this will be accepted in the stack or this is completely off the target? - We are in need to provide solution for (1) and (2) to our customers, obviously we want it to be aligned with bluez architecture. Regards, Ilia Kolominsky iliak@xxxxxx Direct: +972(9)7906231 Mobile: +972(54)909009 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
