RE: Enhancements to allow l2cap channel to use either AMP or BR/EDR

[Marcel Holtmann <marcel@holtmann.org>]

Hi Kevin,

> > > Agree that it should be done "in background" and that a size
> > threshold would be useful.  But who evaluates that threshold?  The
> > bluez kernel components, which essentially implement a transport
> > driver, should not be examining objects (files, phonebooks, etc) size
> > to see if this threshold is met.  Therefore, it would seem Tim's
> > suggestion of having the profile send a 'prefer_amp' bit would be
> > useful, right?
> > 
> > I would do something like "prefer_amp when over 100kb" or something.
> > And
> > then the kernel needs to count. Meaning the L2CAP layer could easily
> > count this by itself.
> 
> What?  Let's say the effect we want is that if the object is greater than, say, 10 megabytes, then we want to use AMP for the transfer.  With your scheme, you want the kernel to count up to 10 megabytes, THEN switch over to AMP?
> No, you don't, he says rhetorically.  :)  

we will see what works out best. I am open for ideas. As I said before,
I know what I don't want for sure. The rest is open for testing and
figuring out if it works or not.

> > Also just starting with setsockopt(bredr_only) and then later on just
> > doing setsockopt(prefer_amp) the userspace application would have
> > control over switching manually.
> 
> How is this really different from your ioctl(switch_now_to_amp) below, which looks very wrong?

The difference is that you change a policy. setsockopt(prefer_amp)
doesn't mean you get switched. It just says that you prefer using an AMP
at this point.

Most application that expect a lot of data would always set the policy
to prefer AMP and if we have the PAL availability then it will switch
right away to AMP.

However with OBEX it might be that you wanna read the first package
first with BR/EDR only and only after knowing the file size make a
decision to prefer AMP or not.

We will see what works out best.

Regards

Marcel