From: Fabien Chevalier <fabchevalier@free.fr>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] [PATCH] SCO flow control
Date: Wed, 07 Jun 2006 22:15:30 +0200 [thread overview]
Message-ID: <448733E2.7090602@free.fr> (raw)
In-Reply-To: <1149189300.28511.61.camel@localhost>
Hi Marcel,
Sorry to be a little late on this answer, however a busy work schedule
and a sunny Sunday prevented me to answer my e-mails for a few days :-)
> so far I only looked at the changes to the HCI core. Please don't rename
> the disconnect timer. This will collide with the changes for automatic
> sniff mode support.
Ok, however as now sniff mode is out, i would suggest i build on top of
it :-)
>
> Can we change the core and add a hci_stream_sco() without breaking the
> API. This would make it easier for me to apply the changes.
I see your point, however i don't see how to bring this feature in
without breaking the hci core API for SCO sockets... :-(
>
> Another question is if we really should queue the data in sk_write_queue
> and not directly in the core. I would prefer to send the data to the
> core and then stream it from there.
That's an interesting question... :-)
I asked it myself when i started to design this feature.
In fact having outgoing packets stored in a socket queue has some
advantages:
* it makes use of the BSD socket send queue, and thus can reuse some
generic socket queue management related functions, which rely on some
well known sk_buff variable (sk_sndbuff, sk_wmem_alloc, sk_rcvbuff,
sk_rmem_alloc ...)
* it makes the thing symetrical, both uplink and downlink path make
use socket queues to buffer data.
As such I thought there were not any valid reason to put in the core...
however if you have suggestions i would be very happy to hear them. :-)
For now i would suggest we do the following:
- for you: have a look at the "whole picture", including the SCO part
patch. This way you would be able to better understand the interaction
between SCO sockets & hci layer. This way you will be able to send in
other comments too. :-)
- for me: * port the patch on top of the 2.6.16-mh1 :-)
* have it to work also when HZ % 333 != 0 ( i've just seen
it wouldn't work properly in this case... )
What do you think of the idea ?
Cheers,
Fabien
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2006-06-07 20:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-29 19:46 [Bluez-devel] [PATCH] SCO flow control Fabien Chevalier
2006-05-29 20:33 ` Marcel Holtmann
2006-05-29 21:39 ` Pieter Poorthuis
2006-05-29 22:21 ` Marcel Holtmann
2006-05-30 13:28 ` Fabien Chevalier
2006-06-01 19:15 ` Marcel Holtmann
2006-06-07 20:15 ` Fabien Chevalier [this message]
2006-06-07 20:30 ` Marcel Holtmann
2006-06-09 17:05 ` Fabien Chevalier
2006-06-09 20:17 ` Marcel Holtmann
2006-06-10 9:24 ` Fabien Chevalier
2006-06-10 22:22 ` Marcel Holtmann
2006-06-10 9:59 ` Fabien Chevalier
2006-06-10 23:14 ` 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=448733E2.7090602@free.fr \
--to=fabchevalier@free.fr \
--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;
as well as URLs for NNTP newsgroup(s).