From: Nick Pelly <npelly@google.com>
To: linux-bluetooth@vger.kernel.org
Subject: RFC: Allow Bluez to select flushable or non-flushable ACL packets with L2CAP_LM_RELIABLE
Date: Tue, 8 Dec 2009 19:50:34 -0800 [thread overview]
Message-ID: <35c90d960912081950t135e3f10m8848e54fde1e596f@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
Right now Bluez always requests flushable ACL packets (but does not
set a flush timeout, so effectively they are non-flushable):
However it is desirable to use an ACL flush timeout on A2DP packets so
that if the ACL packets block for some reason then the LM can flush
them to make room for newer packets.
Is it reasonable for Bluez to use the 0x00 ACL packet boundary flag by
default (non-flushable packet), and let userspace request flushable
packets on A2DP L2CAP sockets with the socket option
L2CAP_LM_RELIABLE.
Make sense? Any other suggestions?
Attached is a rough (untested) patch of what I had in mind.
See core spec 2.E.5.4.2 for reference.
Nick
[-- Attachment #2: 0001-Bluetooth-Send-non-flushable-ACL-packets-by-default.patch --]
[-- Type: application/octet-stream, Size: 3129 bytes --]
From 90f997071d3e795d6e674821c1d0f4057edb5838 Mon Sep 17 00:00:00 2001
From: Nick Pelly <npelly@google.com>
Date: Tue, 8 Dec 2009 19:42:21 -0800
Subject: [PATCH] Bluetooth: Send non-flushable ACL packets by default.
L2CAP sockets can request flushable ACL packets with L2CAP_LM_RELIABLE
Signed-off-by: Nick Pelly <npelly@google.com>
---
include/net/bluetooth/hci.h | 3 +++
net/bluetooth/hci_core.c | 6 ++++--
net/bluetooth/l2cap.c | 10 ++++++++--
3 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index f69f015..c6f6ce5 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -142,11 +142,14 @@ enum {
#define EDR_ESCO_MASK (ESCO_2EV3 | ESCO_3EV3 | ESCO_2EV5 | ESCO_3EV5)
/* ACL flags */
+#define ACL_START_FLUSHABLE 0x00
#define ACL_CONT 0x01
#define ACL_START 0x02
#define ACL_ACTIVE_BCAST 0x04
#define ACL_PICO_BCAST 0x08
+#define ACL_PB_MASK (ACL_CONT | ACL_START)
+
/* Baseband links */
#define SCO_LINK 0x00
#define ACL_LINK 0x01
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index cd06151..aeaf07f 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1200,7 +1200,7 @@ int hci_send_acl(struct hci_conn *conn, struct sk_buff *skb, __u16 flags)
skb->dev = (void *) hdev;
bt_cb(skb)->pkt_type = HCI_ACLDATA_PKT;
- hci_add_acl_hdr(skb, conn->handle, flags | ACL_START);
+ hci_add_acl_hdr(skb, conn->handle, flags);
if (!(list = skb_shinfo(skb)->frag_list)) {
/* Non fragmented */
@@ -1217,12 +1217,14 @@ int hci_send_acl(struct hci_conn *conn, struct sk_buff *skb, __u16 flags)
spin_lock_bh(&conn->data_q.lock);
__skb_queue_tail(&conn->data_q, skb);
+ flags &= ~ACL_PB_MASK;
+ flags |= ACL_CONT;
do {
skb = list; list = list->next;
skb->dev = (void *) hdev;
bt_cb(skb)->pkt_type = HCI_ACLDATA_PKT;
- hci_add_acl_hdr(skb, conn->handle, flags | ACL_CONT);
+ hci_add_acl_hdr(skb, conn->handle, flags);
BT_DBG("%s frag %p len %d", hdev->name, skb, skb->len);
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index ca4d3b4..bf16a6a 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -325,7 +325,7 @@ static inline int l2cap_send_cmd(struct l2cap_conn *conn, u8 ident, u8 code, u16
if (!skb)
return -ENOMEM;
- return hci_send_acl(conn->hcon, skb, 0);
+ return hci_send_acl(conn->hcon, skb, ACL_START);
}
static void l2cap_do_start(struct sock *sk)
@@ -1116,6 +1116,7 @@ static inline int l2cap_do_send(struct sock *sk, struct msghdr *msg, int len)
struct sk_buff *skb, **frag;
int err, hlen, count, sent=0;
struct l2cap_hdr *lh;
+ u16 flags;
BT_DBG("sk %p len %d", sk, len);
@@ -1168,7 +1169,12 @@ static inline int l2cap_do_send(struct sock *sk, struct msghdr *msg, int len)
frag = &(*frag)->next;
}
- if ((err = hci_send_acl(conn->hcon, skb, 0)) < 0)
+ if (l2cap_pi(sk)->force_reliable)
+ flags = ACL_START;
+ else
+ flags = ACL_START_FLUSHABLE;
+
+ if ((err = hci_send_acl(conn->hcon, skb, flags)) < 0)
goto fail;
return sent;
--
1.6.5.3
next reply other threads:[~2009-12-09 3:50 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-09 3:50 Nick Pelly [this message]
2009-12-09 5:06 ` RFC: Allow Bluez to select flushable or non-flushable ACL packets with L2CAP_LM_RELIABLE Marcel Holtmann
2009-12-09 5:26 ` Nick Pelly
2009-12-09 6:13 ` Nick Pelly
2009-12-10 22:03 ` Marcel Holtmann
2009-12-16 21:59 ` Nick Pelly
2009-12-16 23:36 ` Marcel Holtmann
2009-12-16 23:48 ` Nick Pelly
2009-12-18 23:05 ` Marcel Holtmann
2009-12-18 23:23 ` Nick Pelly
2009-12-18 23:50 ` Marcel Holtmann
2009-12-19 0:12 ` Nick Pelly
2009-12-19 0:26 ` Marcel Holtmann
2009-12-19 1:50 ` Nick Pelly
2009-12-19 2:05 ` Marcel Holtmann
2009-12-19 3:00 ` Nick Pelly
2009-12-19 3:27 ` Marcel Holtmann
2009-12-19 3:00 ` Perelet, Oleg
2009-12-19 7:46 ` Johan Hedberg
2009-12-19 0:16 ` Nick Pelly
2010-03-09 20:07 ` Nick Pelly
2010-03-09 20:45 ` Marcel Holtmann
2010-06-16 11:40 ` Luiz Augusto von Dentz
2010-06-16 12:04 ` Suraj
2010-06-16 15:14 ` Luiz Augusto von Dentz
2010-06-16 15:45 ` Suraj
2010-06-16 16:26 ` Nick Pelly
2010-06-17 5:09 ` Suraj
2010-06-16 14:15 ` Nick Pelly
2010-12-09 10:37 ` Andrei Emeltchenko
2010-12-09 16:55 ` Nick Pelly
2010-12-10 4:25 ` Suraj Sumangala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=35c90d960912081950t135e3f10m8848e54fde1e596f@mail.gmail.com \
--to=npelly@google.com \
--cc=linux-bluetooth@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).