New Christmas SCO flow control patch
Subsystems (2)
PATCH 1/1 New Christmas SCO flow control patch
Marcel, Brad, Jose
Please find attached another rework of the SCO flow control patch. This patch is against 2.6.19.1.
I hope i'm getting closer to something that's good enough for inclusion in mh patches (Marcel, i'm waiting for your comments here ;-) ).
The only change compared to the previous release, is that the callback is gone.
The send complete aknowledge is now done using the skb destructor. As a consequence the sco feature is still strongly linked to sk_buffs & generic socket behaviour. However it looks like sound-of-bluez will be built on top of the socket layer, and won't replace it... so it looks OK for me to still have that strong dependancy on sockets.
Some design points are explained below (just a copy of one of my previous e-mails):
Point 1 : Why rely on hrtimers ?
As discussed previously on the list, there is no transport agnostic way to throttle ourselves to send data at the right rate.
SCO flow control support at HCI level is optionnal, thus we cannot rely on it.
Relying on isochronous USB transfer is not good as well, as it poses some architectural issues underlined by Marcel's previous e-mails. Moreover i suspect this to rely on USB host controller clock, which is unrelated to the bluetooth chip clock, and thus will suffer the same clock offset drawback that a timer based approach. So at some point we have to throttle ourselves, and timers can be used for that.
Point 2 : What about buffer settings ?
Audio API expects the application to specify a 'buffer size' and 'period size'.
Period size is the size of data that sound card hardware processes at a time.
Buffer size is a multiple of the period size, and is shared by both ALSA and the hardware
to move data from one to another.
One important thing to understand is that the biggest the buffer, the longer the added latency added.
That's why xmms's playing buffer default to 500 ms, while Ekiga's one is as small as two period sizes.
As it's up to the application to choose its buffer size, there is a need for SCO sockets to expose and API
to change the size of the buffer. There already exist such an API, which is SO_SNDBUF and SO_RCVBUF
setsockopt options, however the measurment does include the size of in-kernel data structures, which means the application has no way to tell the exact size of the buffer without knowing how big are the kernel data structures. For ALSA this is not acceptable.
So i introduces SCO_TXBUFS and SCO_RXBUFS socket options to be able to specify a number of sco packets.
There is a nice tutorial on this subject by ALSA project that can be found on:
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html
Cheers,
Fabien
include/net/bluetooth/hci.h +7 -0
@@ -767,6 +767,9 @@ struct hci_dev_stats {__u32 byte_tx; }; +/* Fields down there are mostly the same as hci_dev, +as this structure is meant to communicate info +to userspace */ struct hci_dev_info {__u16 dev_id;char name[8 ];
@@ -782,9 +785,13 @@ struct hci_dev_info {__u32 link_policy;__u32 link_mode; +/* Maximum transmition unit for ACL packets */ __u16 acl_mtu; +/* Number of ACL packets the baseband is able to buffer */ __u16 acl_pkts; +/* Maximum transmition unit for SCO packets */ __u16 sco_mtu; +/* Number of SCO packets the baseband is able to buffer */ __u16 sco_pkts;struct hci_dev_stats stat;
include/net/bluetooth/hci_core.h +22 -6
@@ -25,6 +25,8 @@#ifndef __HCI_CORE_H#define __HCI_CORE_H +#include <linux/hrtimer.h> +#include <net/bluetooth/hci.h> /* HCI upper protocols */
@@ -88,12 +90,18 @@ struct hci_dev {unsigned long quirks;atomic_t cmd_cnt; +/* Number of available controller buffers for ACL packets */ unsigned int acl_cnt; -unsigned int sco_cnt; +/* Number of available controller buffers for SCO packets */ +atomic_t sco_cnt; +/* Maximum transmition unit for ACL packets */ unsigned int acl_mtu; +/* Maximum transmition unit for SCO packets */ unsigned int sco_mtu; +/* Maximum number of ACL packets the controller is able to buffer */ unsigned int acl_pkts; +/* Maximum number of SCO packets the controller is able to buffer */ unsigned int sco_pkts;unsigned long cmd_last_tx;
@@ -145,12 +153,12 @@ struct hci_conn {struct list_head list;atomic_t refcnt; -spinlock_t lock;bdaddr_t dst;__u16 handle;__u16 state;__u8 mode; +/* type : ACL or SCO */ __u8 type;__u8 out;__u8 attempt;
@@ -162,10 +170,17 @@ struct hci_conn {__u8 power_save;unsigned long pend; -unsigned int sent; - -struct sk_buff_head data_q; - +/* sent represents the number of packets this connections +has "on the wire" : .... oh f.... there are no wire +with bluetooth. By on the wire, i mean packets that have been sent +to the HCI device, and that are still in its buffers */ +atomic_t sent; + +struct sk_buff_head out_q; + +/* tx timer : used only for SCO */ +struct hrtimer tx_timer; +/* Disconnect timer */ struct timer_list disc_timer;struct timer_list idle_timer;
@@ -175,6 +190,7 @@ struct hci_conn {struct hci_dev *hdev;void *l2cap_data; +/* private use for sco */ void *sco_data;void *priv;
net/bluetooth/hci_conn.c +8 -3
@@ -184,7 +184,9 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst) conn->power_save =1 ; -skb_queue_head_init (&conn->data_q); +skb_queue_head_init (&conn->out_q); + +hrtimer_init (&conn->tx_timer,CLOCK_MONOTONIC ,HRTIMER_NORESTART );init_timer (&conn->disc_timer); conn->disc_timer.function = hci_conn_timeout;
@@ -195,6 +197,7 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst) conn->idle_timer.data = (unsigned long ) conn;atomic_set (&conn->refcnt,0 ); +atomic_set (&conn->sent,0 );hci_dev_hold (hdev);
@@ -221,6 +224,8 @@ int hci_conn_del(struct hci_conn *conn)del_timer (&conn->disc_timer); +hrtimer_cancel (&conn->tx_timer); +if (conn->type ==SCO_LINK ) {struct hci_conn *acl = conn->link;if (acl) {
@@ -233,7 +238,7 @@ int hci_conn_del(struct hci_conn *conn) sco->link =NULL ;/* Unacked frames */ - hdev->acl_cnt += conn->sent; + hdev->acl_cnt +=atomic_read (&conn->sent); }tasklet_disable (&hdev->tx_task);
@@ -246,7 +251,7 @@ int hci_conn_del(struct hci_conn *conn)tasklet_enable (&hdev->tx_task); -skb_queue_purge (&conn->data_q); +skb_queue_purge (&conn->out_q);hci_dev_put (hdev);
net/bluetooth/hci_core.c +105 -40
256 lines not on this page · raw message
net/bluetooth/hci_event.c +7 -7
@@ -320,7 +320,7 @@ static void hci_cc_info_param(struct hci_dev *hdev, __u16 ocf, struct sk_buff *s lv = (struct hci_rp_read_loc_version *) skb->data;if (lv->status) { -BT_DBG ("%s READ_LOCAL_VERSION failed %d" , hdev->name, lf->status); +BT_DBG ("%s READ_LOCAL_VERSION failed %d" , hdev->name, lv->status);break ; }
@@ -382,7 +382,7 @@ static void hci_cc_info_param(struct hci_dev *hdev, __u16 ocf, struct sk_buff *s } hdev->acl_cnt = hdev->acl_pkts; - hdev->sco_cnt = hdev->sco_pkts; +atomic_set (&hdev->sco_cnt, hdev->sco_pkts);BT_DBG ("%s mtu: acl %d, sco %d max_pkt: acl %d, sco %d" , hdev->name, hdev->acl_mtu, hdev->sco_mtu, hdev->acl_pkts, hdev->sco_pkts);
@@ -880,15 +880,15 @@ static inline void hci_num_comp_pkts_evt(struct hci_dev *hdev, struct sk_buff *s conn =hci_conn_hash_lookup_handle (hdev, handle);if (conn) { - conn->sent -= count; +atomic_sub (count, &conn->sent); -if (conn->type ==SCO_LINK ) { -if ((hdev->sco_cnt += count) > hdev->sco_pkts) - hdev->sco_cnt = hdev->sco_pkts; - }else { +if (conn->type ==ACL_LINK ) {if ((hdev->acl_cnt += count) > hdev->acl_pkts) hdev->acl_cnt = hdev->acl_pkts; } +/* Note : we do not use the "number of completed packets" event +to increment hdev->sco_cnt, as this feature is only optionnally support +by bluetooth controllers. So there is no if branch for SCO_LINK packets */ } }hci_sched_tx (hdev);
include/net/bluetooth/sco.h +3 -5
@@ -26,12 +26,7 @@#define __SCO_H/* SCO defaults */ -#define SCO_DEFAULT_MTU 500 -#define SCO_DEFAULT_FLUSH_TO 0xFFFF -#define SCO_CONN_TIMEOUT (HZ * 40) -#define SCO_DISCONN_TIMEOUT (HZ * 2) -#define SCO_CONN_IDLE_TIMEOUT (HZ * 60)/* SCO socket address */ struct sockaddr_sco {
@@ -51,6 +46,9 @@ struct sco_conninfo {__u8 dev_class[3 ]; }; +#define SCO_TXBUFS 0x03 +#define SCO_RXBUFS 0x04 +/* ---- SCO connections ---- */ struct sco_conn {struct hci_conn *hcon;
net/bluetooth/sco.c +144 -16
255 lines not on this page · raw message
begin:vcard
fn:Fabien CHEVALIER
n:CHEVALIER;Fabien
org:SILICOM
adr:;;4 rue de Jouanet;RENNES ATALANTE;;35700;FRANCE email;internet:[email protected] title:Software & Studies Engineer tel;work:+33 (0) 2 99 84 17 17
version:2.1
end:vcard