From: Jose Vasconcellos <vasmac@gmail.com>
To: bluez-devel@lists.sourceforge.net
Subject: [Bluez-devel] SCO packet processing
Date: Mon, 02 Oct 2006 21:05:57 -0400 [thread overview]
Message-ID: <4521B775.6040001@gmail.com> (raw)
Hello,
I've been studying the SCO packet processing to understand how it works.
There are a few things that I noticed that don't seem quite right. I'll
attempt
to explain.
In the SCO transmit path, data gets put in a skb and then queued. There's
a tasklet that will dequeue and send the skb to the hci driver. This tasklet
is scheduled when data needs to be sent or when there's a HCI event
HCI_EV_NUM_COMP_PKTS. This works fine for an ACL link and it could work
for a non-USB SCO transport. However, for USB HCI, the SCO data is carried
by the isochronous transport that doesn't require explicit flow control. The
problem is that the current code (hci_sched_sco in hci_core.c) will send all
packets to the hci layer with no flow control. That explains why application
kludges have been introduced to avoid loosing packets.
Note that for non-USB links (i.e. UART), the current code is not correct
either as it doesn't enable HCI_EV_NUM_COMP_PKTS anywhere. Also,
the value of hdev->sco_cnt is never decremented.
Last May, Fabien Chevalier posted some patches to avoid this problem.
His approach of using timers didn't work for me but I think this is the
wrong
way to go about it. What is needed is a proper flow control mechanism
between
the bluetooth module and the hci layer for the case of USB HCI transport.
I'm thinking that a callback is necessary that is invoked by hci_usb to
kickstart the process.
I also have issues with hci_sched_sco. I think it should interleave skb from
different active SCO sockets. Currently, it sends too many skbs from the
same socket flooding the dongle's buffers and potentially starving other
SCO channels.
I realize SCO handling has not been a priority and it sort of works.
Is there much interest in getting it right?
Regards,
Jose
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next reply other threads:[~2006-10-03 1:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-03 1:05 Jose Vasconcellos [this message]
2006-10-04 8:33 ` [Bluez-devel] SCO packet processing Marcel Holtmann
2006-10-04 12:00 ` Jose Vasconcellos
-- strict thread matches above, loose matches on Subject: below --
2006-10-03 3:26 Jose Vasconcellos
2006-10-04 3:30 ` Brad Midgley
2006-10-04 8:27 ` Marcel Holtmann
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=4521B775.6040001@gmail.com \
--to=vasmac@gmail.com \
--cc=bluez-devel@lists.sourceforge.net \
/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