Re: [RFC] Interface to set LE connection parameters

["Gustavo F. Padovan" <padovan@profusion.mobi>]

Hi Ville,

* Ville Tervo <ville.tervo@nokia.com> [2010-11-15 17:17:39 +0200]:

> Hi Tim,
> 
> Please stop top posting on this ml.
> 
> On Mon, Nov 15, 2010 at 03:24:29PM +0100, ext tim.howes@accenture.com wrote:
> > Hi Ville,
> > 
> > As you note the different profiles would likely have different connection parameters.  The different profiles may be running on the same LE link (indeed the same L2CAP [fixed] channel).
> > 
> 
> I guess the latency should override power requirements. Low power profile can
> operate on low latency link but low latency profile fails on high latency. Of
> course this gets much more complicated if there are more requirements.
> 
> Are these (latency and power) the only characteristics we need to deal with.
> There might be some also. I'm not too familiar with profile drafts.
> 
> > Do you have a view on how the different profiles - on the same link - would have different requests arbitrated, and where that arbitration would be done?  I'd imagine that the API towards the profiles should be of the abstract form - such as you mention (eg BT_LE_LOW_LAT).  This would make it easier to arbitrate the different requests, as compared to if the profiles see an API of the "numerical" form (eg interval = N ms).  I guess the arbitration could happen in user or kernel space; as long as there is something with singleton-like semantics to do it.
> > 
> 
> I think I need to get more details from profile specs and try to find out the
> requirements from them.
> 
> Right now I'm trying to find out what would be the right interface from kernel
> to user space. 

If you go with the abstraction in userspace (inside bluetoothd) will be easy to
create usage profiles on top of it or even do a fine tune of the parameters
for a specific usage. New profiles should be created in the future and we
can't foresee its requirements. And I'm seeing that we will have many
many different use cases for LE in the future.  It can be hard to extend
the API if we do the abstraction in the kernel because we can't break
the API that we are going to create.

We also have to check if we really need all the parameters you are
proposing, maybe we can simplify that API. What about you send a e-mail
explaining why we should add each parameter to the API?

-- 
Gustavo F. Padovan
http://profusion.mobi