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, 16 Dec 2009 15:36:36 -0800 [thread overview]
Message-ID: <1261006596.4041.39.camel@localhost.localdomain> (raw)
In-Reply-To: <35c90d960912161359u2b3f9b2fi875288896a7a8478@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.
> >>
> >> Got it, how about introducing
> >>
> >> #define L2CAP_LM_FLUSHABLE 0x0040
> >
> > that l2cap_sock_setsockopt_old() sets this didn't give you a hint that
> > we might wanna deprecate this socket options ;)
> >
> > I need to read up on the flushable stuff, but in the end it deserves its
> > own socket option. Also an ioctl() to actually trigger Enhanced flush
> > might be needed.
> >
> >> struct l2cap_pinfo {
> >> ...
> >> __u8 flushable;
> >> }
> >
> > Sure. In the long run we need to turn this into a bitmask. We are just
> > wasting memory here.
>
> Attached is an updated patch, that checks the LMP features bitmask
> before using the new non-flushable packet type.
>
> I am still using L2CAP_LM_FLUSHABLE socket option in
> l2cap_sock_setsockopt_old(), which I don't think you are happy with.
> So how about a new option:
>
> SOL_L2CAP, L2CAP_ACL_FLUSH
> which has a default value of 0, and can be set to 1 to make the ACL
> data sent by this L2CAP socket flushable.
>
> In a later commit we would then add
> SOL_ACL, ACL_FLUSH_TIMEOUT
> That is used to set an automatic flush timeout for the ACL link on a
> L2CAP socket. Note that SOL_ACL is new.
can I stop you right here (without even looking at the patch). We do
have the generic SOL_BLUETOOTH that you should be using. So adding
SOL_ACL is not a viable option at all.
Remember that it would also be nice if this works with RFCOMM sockets.
Even if the usefulness is limited for these sockets.
Regards
Marcel
next prev parent reply other threads:[~2009-12-16 23:36 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
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 [this message]
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=1261006596.4041.39.camel@localhost.localdomain \
--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).