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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.