[RFC v2 1/5] Bluetooth: Only schedule LE tx links if LE-capable

[RFC v2 1/5] Bluetooth: Only schedule LE tx links if LE-capable

[Peter Hurley]

T25seSBwZXJmb3JtIHR4IHNjaGVkdWxpbmcgZm9yIExFIGxpbmtzIGlmIHRoZSBob3N0IGNvbnRy
b2xsZXINCmlzIExFLWNhcGFibGUuDQoNClNpZ25lZC1vZmYtYnk6IFBldGVyIEh1cmxleSA8cGV0
ZXJAaHVybGV5c29mdHdhcmUuY29tPg0KLS0tDQogbmV0L2JsdWV0b290aC9oY2lfY29yZS5jIHwg
ICAgNCArKystDQogMSBmaWxlcyBjaGFuZ2VkLCAzIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb25z
KC0pDQoNCmRpZmYgLS1naXQgYS9uZXQvYmx1ZXRvb3RoL2hjaV9jb3JlLmMgYi9uZXQvYmx1ZXRv
b3RoL2hjaV9jb3JlLmMNCmluZGV4IDgxNTI2OWIuLjQ3YTMxZmEgMTAwNjQ0DQotLS0gYS9uZXQv
Ymx1ZXRvb3RoL2hjaV9jb3JlLmMNCisrKyBiL25ldC9ibHVldG9vdGgvaGNpX2NvcmUuYw0KQEAg
LTE5OTUsNyArMTk5NSw5IEBAIHN0YXRpYyB2b2lkIGhjaV90eF90YXNrKHVuc2lnbmVkIGxvbmcg
YXJnKQ0KIA0KIAloY2lfc2NoZWRfZXNjbyhoZGV2KTsNCiANCi0JaGNpX3NjaGVkX2xlKGhkZXYp
Ow0KKwkvKiBPbmx5IHNjaGVkdWxlIGxlIGxpbmtzIGlmIGRldmljZSBpcyBsZS1jYXBhYmxlICov
DQorCWlmIChsbXBfbGVfY2FwYWJsZShoZGV2KSkNCisJCWhjaV9zY2hlZF9sZShoZGV2KTsNCiAN
CiAJLyogU2VuZCBuZXh0IHF1ZXVlZCByYXcgKHVua25vd24gdHlwZSkgcGFja2V0ICovDQogCXdo
aWxlICgoc2tiID0gc2tiX2RlcXVldWUoJmhkZXYtPnJhd19xKSkpDQotLSANCjEuNy40LjENCg0K

Re: [RFC v2 1/5] Bluetooth: Only schedule LE tx links if LE-capable

[Luiz Augusto von Dentz]

Hi Peter,

On Thu, Aug 18, 2011 at 3:37 AM, Peter Hurley <peter@hurleysoftware.com> wrote:
> Only perform tx scheduling for LE links if the host controller
> is LE-capable.
>
> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
> ---
>  net/bluetooth/hci_core.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 815269b..47a31fa 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -1995,7 +1995,9 @@ static void hci_tx_task(unsigned long arg)
>
>        hci_sched_esco(hdev);
>
> -       hci_sched_le(hdev);
> +       /* Only schedule le links if device is le-capable */
> +       if (lmp_le_capable(hdev))
> +               hci_sched_le(hdev);
>
>        /* Send next queued raw (unknown type) packet */
>        while ((skb = skb_dequeue(&hdev->raw_q)))
> --
> 1.7.4.1
>
>

Any reasons why you choose to not add the check inside hci_sched_le?

-- 
Luiz Augusto von Dentz

Re: [RFC v2 1/5] Bluetooth: Only schedule LE tx links if LE-capable

[Andre Guedes]

Hi Peter,

On Aug 17, 2011, at 9:37 PM, Peter Hurley wrote:

> Only perform tx scheduling for LE links if the host controller
> is LE-capable.
> 
> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
> ---
> net/bluetooth/hci_core.c |    4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 815269b..47a31fa 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -1995,7 +1995,9 @@ static void hci_tx_task(unsigned long arg)
> 
> 	hci_sched_esco(hdev);
> 
> -	hci_sched_le(hdev);
> +	/* Only schedule le links if device is le-capable */
> +	if (lmp_le_capable(hdev))
> +		hci_sched_le(hdev);


You may use lmp_host_le_capable macro here since it tells you if
the _host_ supports LE (lmp_le_capable macro tells you if the
_controller_ supports LE).

BR,
Andre

Re: [RFC v2 1/5] Bluetooth: Only schedule LE tx links if LE-capable

[Anderson Lizardo]

Hi Peter,

On Thu, Aug 18, 2011 at 7:17 AM, Peter Hurley <peter@hurleysoftware.com> wrote:
> On Thu, 2011-08-18 at 03:43 -0400, Luiz Augusto von Dentz wrote:
>> Any reasons why you choose to not add the check inside hci_sched_le?
>
> Only to make it really obvious that LE transmission is not required on
> the vast majority of BT controllers :)

... yet. Are you aware LE is not optional on Bluetooth 4.0? Therefore
any modern BT device claiming to support 4.0 will have LE support on
its controller (host support is another thing).

But I suppose we will still see plenty of 2.1 devices for a long time...

My two cents,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

Re: [RFC v2 1/5] Bluetooth: Only schedule LE tx links if LE-capable

[Peter Hurley]

SGkgQW5kcmUsDQoNCk9uIFRodSwgMjAxMS0wOC0xOCBhdCAxODoxMiAtMDQwMCwgQW5kcmUgR3Vl
ZGVzIHdyb3RlOg0KPiBZb3UgbWF5IHVzZSBsbXBfaG9zdF9sZV9jYXBhYmxlIG1hY3JvIGhlcmUg
c2luY2UgaXQgdGVsbHMgeW91IGlmDQo+IHRoZSBfaG9zdF8gc3VwcG9ydHMgTEUgKGxtcF9sZV9j
YXBhYmxlIG1hY3JvIHRlbGxzIHlvdSBpZiB0aGUNCj4gX2NvbnRyb2xsZXJfIHN1cHBvcnRzIExF
KS4NCg0KVGhhbmtzIGZvciBwb2ludGluZyB0aGF0IG91dC4gVGhpcyBzZXJpZXMgaXMgYWN0dWFs
bHkgc2V2ZXJhbCBtb250aHMgb2xkDQphbmQgc28sIHByZWRhdGVzIHRoZSBpbmNsdXNpb24gb2Yg
bG1wX2hvc3RfbGVfY2FwYWJsZSwgYnV0IEknbGwga2VlcA0KdGhhdCBpbiBtaW5kIGZvciBmdXR1
cmUgY29kZS4NCg0KVGhpcyBwYXJ0aWN1bGFyIHRlc3Qgd2lsbCBiZSBzdXBlcmZsdW91cyB3aGVu
IEx1aXoncyBwcm9wb3NhbCBoZXJlDQpodHRwOi8vd3d3LnNwaW5pY3MubmV0L2xpc3RzL2xpbnV4
LWJsdWV0b290aC9tc2cxNTU1OC5odG1sIGlzIGFjY2VwdGVkDQood2hpY2ggdHJhY2tzIHRoZSBj
b3VudCBvZiBMRSBjb25uZWN0aW9ucyBhbmQgZG9lcyBub3QgcGVyZm9ybSBMRQ0Kc2NoZWR1bGlu
ZyBpZiB0aGF0IGNvdW50IGlzIDApLiBJbW8sIHRoYXQgcHJvcG9zYWwgaXMgYSBtb3JlIGNvbXBs
ZXRlDQphbmQgZWZmZWN0aXZlIGFwcHJvYWNoIHRvIGJ5cGFzcyBMRSBzY2hlZHVsaW5nIHdoZW4g
dW5uZWNlc3NhcnkuDQoNClJlZ2FyZHMsDQpQZXRlciBIdXJsZXkNCg0K

Re: [RFC v2 1/5] Bluetooth: Only schedule LE tx links if LE-capable

[Peter Hurley]

Hi Anderson,

On Fri, 2011-08-19 at 06:52 -0400, Anderson Lizardo wrote:
> Hi Peter,
> 
> On Thu, Aug 18, 2011 at 7:17 AM, Peter Hurley <peter@hurleysoftware.com> wrote:
> > On Thu, 2011-08-18 at 03:43 -0400, Luiz Augusto von Dentz wrote:
> >> Any reasons why you choose to not add the check inside hci_sched_le?
> >
> > Only to make it really obvious that LE transmission is not required on
> > the vast majority of BT controllers :)
> 
> ... yet. Are you aware LE is not optional on Bluetooth 4.0? Therefore
> any modern BT device claiming to support 4.0 will have LE support on
> its controller (host support is another thing).

I was aware of that, but that's an important point you make.

> But I suppose we will still see plenty of 2.1 devices for a long time...

As I noted to Andre earlier, this particular test will be unnecessary
when Luiz's proposal (using the LE connection count to bypass LE
scheduling when 0). I feel Luiz's approach is the more effective
approach anyway.

Regards,
Peter Hurley