From: Gustavo Padovan <padovan@profusion.mobi>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: Mat Martineau <mathewm@codeaurora.org>,
linux-bluetooth@vger.kernel.org, peter@hurleysoftware.com
Subject: Re: [PATCH 0/3] RFC: prioritizing data over HCI
Date: Sat, 6 Aug 2011 15:53:45 -0300 [thread overview]
Message-ID: <20110806185345.GC2537@joana> (raw)
In-Reply-To: <CABBYNZLCO6aesaXa15B6kKYy2HEohF+ySCq4kGEgJF7_Ai37kA@mail.gmail.com>
Hi Luiz,
* Luiz Augusto von Dentz <luiz.dentz@gmail.com> [2011-08-06 01:49:24 +0300]:
> Hi Gustavo,
>
> On Fri, Aug 5, 2011 at 10:14 PM, Gustavo Padovan <padovan@profusion.mobi> wrote:
> >
> > Only ERTM needs to have its own queue, Basic and Streaming mode doesn't need
> > to change, they can use the same queue they are using now.
>
> The guaranteed channels also seems to need separated queue, actually
> even best effort channels could use QoS (see page 1442 :5.3 QUALITY
> OF SERVICE (QOS) OPTION). Note this is a general option which is then
> negotiated also on HCI level, it seems completely independent of ERTM.
What I tried to say is that ERTM needs to prioritize some frames (SREJ, REJ,
poll and final bits, resends) to improve the throughput. This is independent of
the QoS of the channel. So we need to postpone the queueing into conn->data_q
until the last moment before send it to the hci_dev.
>
> The per channel queuing is almost a must have if we really want to be
> able to implement any QoS, because then we can track exactly what
> channels are sending, calculate if we can attend the QoS needs and so
> on. But I don't think doing this on L2CAP level is a good idea,
> because it create a circular dependency with HCI and the pull mode
> might create a locking nightmare, not to mention L2CAP is already
> quite big.
>
> One of the solution Ive been thinking is to have an HCI Channel (e.g.
> struct hci_chan) abstraction, which would be responsible for queueing
> and storing necessary information for scheduling. This could be
> implemented directly in HCI level (hci_conn.c) so L2CAP can still push
> data to HCI by using the HCI Channel (l2cap_chan->hci_chan). How about
> that?
This doesn't work ERTM. I've been thinking on keep both the normal ERTM queue
and the prio qeue inside L2CAP and the create some callbacks, then HCI can ask
L2CAP channel to deliver the frames it have queued. ERTM would first clear it
prio queue and then the normal queue, and before send each of packets to HCI
ERTM have to set packet header properly.
You approach can work for the other L2CAP modes.
Gustavo
prev parent reply other threads:[~2011-08-06 18:53 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-03 13:11 [PATCH 0/3] RFC: prioritizing data over HCI Luiz Augusto von Dentz
2011-08-03 13:11 ` [RFC 1/3] Bluetooth: " Luiz Augusto von Dentz
2011-08-03 16:25 ` Peter Hurley
2011-08-03 17:49 ` Luiz Augusto von Dentz
2011-08-03 20:44 ` Gustavo Padovan
2011-08-03 20:53 ` Peter Hurley
2011-08-04 9:04 ` Luiz Augusto von Dentz
2011-08-03 13:11 ` [RFC 2/3] Bluetooth: set skbuffer priority based on L2CAP socket priority Luiz Augusto von Dentz
2011-08-03 13:11 ` [RFC 3/3] Bluetooth: make use sk_priority to priritize RFCOMM packets Luiz Augusto von Dentz
2011-08-03 21:14 ` [PATCH 0/3] RFC: prioritizing data over HCI Peter Hurley
2011-08-04 8:20 ` Luiz Augusto von Dentz
2011-08-04 12:55 ` Peter Hurley
2011-08-04 17:37 ` Mat Martineau
2011-08-04 23:09 ` Peter Hurley
2011-08-05 19:12 ` Gustavo Padovan
2011-08-08 23:29 ` Mat Martineau
2011-08-09 4:32 ` Gustavo Padovan
2011-08-10 17:38 ` Mat Martineau
2011-08-10 18:16 ` Luiz Augusto von Dentz
2011-08-10 22:15 ` Mat Martineau
2011-08-10 19:43 ` Peter Hurley
2011-08-11 0:18 ` Marcel Holtmann
2011-08-05 6:09 ` Luiz Augusto von Dentz
2011-08-05 19:14 ` Gustavo Padovan
2011-08-05 22:49 ` Luiz Augusto von Dentz
2011-08-06 18:53 ` Gustavo Padovan [this message]
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=20110806185345.GC2537@joana \
--to=padovan@profusion.mobi \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=mathewm@codeaurora.org \
--cc=peter@hurleysoftware.com \
/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).