From: Marcel Holtmann <marcel@holtmann.org>
To: Nick Pelly <npelly@google.com>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: RFC: Allow Bluez to select flushable or non-flushable ACL packets with L2CAP_LM_RELIABLE
Date: Wed, 09 Dec 2009 06:06:15 +0100 [thread overview]
Message-ID: <1260335175.2901.20.camel@violet> (raw)
In-Reply-To: <35c90d960912081950t135e3f10m8848e54fde1e596f@mail.gmail.com>
Hi Nick,
> 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.
the reliable option has a different meaning. It comes back from the old
Bluetooth 1.1 qualification days where we had to tests on L2CAP that had
to confirm that we can detect malformed packets and report them. These
days it is just fine to drop them.
You can not just blindly use ACL_START_FLUSHABLE without proper version
checking. This feature has been introduced later and will not work with
all stacks out there. Please go through the different spec. versions to
see the difference.
Regards
Marcel
next prev parent reply other threads:[~2009-12-09 5:06 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-09 3:50 RFC: Allow Bluez to select flushable or non-flushable ACL packets with L2CAP_LM_RELIABLE Nick Pelly
2009-12-09 5:06 ` Marcel Holtmann [this message]
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=1260335175.2901.20.camel@violet \
--to=marcel@holtmann.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=npelly@google.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).