Re: RFC: Allow Bluez to select flushable or non-flushable ACL packets with L2CAP_LM_RELIABLE

[Nick Pelly <npelly@google.com>]

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

On Tue, Dec 8, 2009 at 9:06 PM, Marcel Holtmann <marcel@holtmann.org> wrote:

> 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.
>

Ok, how about introducing

#define L2CAP_LM_FLUSHABLE 0x0040

struct l2cap_pinfo {
   ...
   __u8 flushable;
}


> 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.
>

Will do.

Nick

[-- Attachment #2: Type: text/html, Size: 1929 bytes --]