Implementation of name-resolve procedures in mgmtops

Implementation of name-resolve procedures in mgmtops

[Ilia, Kolominsky]

Hi Johan,
Could you please outline the intended mechanics for the new
Name-resolve procedures in mgmtops?
- What is the purpose of Confirm Name command?
( I see that you`d added it but not implemented )
- What are the main differences in the mechanics between
the hciops and mgmtops?
- Are there any changes in user behavior?

Regards

Ilia Kolominsky
iliak@ti.com
Direct:  +972(9)7906231
Mobile: +972(54)909009

Re: Implementation of name-resolve procedures in mgmtops

[Johan Hedberg]

Hi Ilia,

On Mon, Oct 31, 2011, Ilia, Kolominsky wrote:
> Could you please outline the intended mechanics for the new
> Name-resolve procedures in mgmtops?
> - What is the purpose of Confirm Name command?
> ( I see that you`d added it but not implemented )
> - What are the main differences in the mechanics between
> the hciops and mgmtops?
> - Are there any changes in user behavior?

We already discussed this on IRC, but I'll recap here so that it gets
stored in the mailing list archives. This way people can also correct me
if I remember something wrong about what we agreed in Prague.

Regarding mgmtops vs hciops, the idea (as long as we hold on to hciops)
is that hciops roughly emulates what the kernel will do when accessed
through the mgmt interface. That also means that the adapter_ops API
should be modeled more or less according to the mgmt interface (e.g. the
resolve_name callback needs to go and a confirm_name callback needs to
be added).

During a device discovery session the kernel will set the (new) Confirm
Name field in mgmt_ev_device_found to 1 whenever the kernel doesn't know
if know the name for that device or not. Upon receiving such an event
user-space (bluetoothd) will check its storage and respond with the
(new) Confirm Name command. The field in mgmt_ev_device found would be
set to 1 e.g. for any non-EIR inquiry result for a device we haven't
received a confirm_name command for previously (during the same
discovery session) and for any EIR result which doesn't contain a full
name.

Each "unknown name" device that user-space tells the kernel about gets
added to a list and once the currently ongoing inquiry finishes the
kernel proceeds with trying to resolve the name for each device in the
list, one at a time. For efficiency, this list should be sorted by
strongest RSSI first so that devices which are with a higher likelihood
closer to us get their names resolved first. The kernel will also wait a
few seconds (2 sounds like an ok value?) if user space hasn't yet
responded with a name confirmation for a device when inquiry finishes.
Once the list of names to be resolved is empty the device discovery is
deemed complete.

Johan

RE: Implementation of name-resolve procedures in mgmtops

[Ilia, Kolominsky]

Hi

> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> owner@vger.kernel.org] On Behalf Of Johan Hedberg
> Sent: Tuesday, November 01, 2011 12:07 PM
> To: Ilia, Kolominsky
> Cc: linux-bluetooth@vger.kernel.org
> Subject: Re: Implementation of name-resolve procedures in mgmtops
> 
> Hi Ilia,
> 
> On Mon, Oct 31, 2011, Ilia, Kolominsky wrote:
> > Could you please outline the intended mechanics for the new
> > Name-resolve procedures in mgmtops?
> > - What is the purpose of Confirm Name command?
> > ( I see that you`d added it but not implemented )
> > - What are the main differences in the mechanics between
> > the hciops and mgmtops?
> > - Are there any changes in user behavior?
> 
> We already discussed this on IRC, but I'll recap here so that it gets
> stored in the mailing list archives. This way people can also correct
> me
> if I remember something wrong about what we agreed in Prague.
> 
> Regarding mgmtops vs hciops, the idea (as long as we hold on to hciops)
> is that hciops roughly emulates what the kernel will do when accessed
> through the mgmt interface. That also means that the adapter_ops API
> should be modeled more or less according to the mgmt interface (e.g.
> the
> resolve_name callback needs to go and a confirm_name callback needs to
> be added).

Maybe we should keep resolve_name() method, so the user will be able to
perform name resolution for a specific device without
triggering the whole discovery process? This will allow more flexibility
for the user.

> 
> During a device discovery session the kernel will set the (new) Confirm
> Name field in mgmt_ev_device_found to 1 whenever the kernel doesn't
> know
> if know the name for that device or not. Upon receiving such an event
> user-space (bluetoothd) will check its storage and respond with the
> (new) Confirm Name command. The field in mgmt_ev_device found would be
> set to 1 e.g. for any non-EIR inquiry result for a device we haven't
> received a confirm_name command for previously (during the same
> discovery session) and for any EIR result which doesn't contain a full
> name.
> 
> Each "unknown name" device that user-space tells the kernel about gets
> added to a list and once the currently ongoing inquiry finishes the
> kernel proceeds with trying to resolve the name for each device in the
> list, one at a time. For efficiency, this list should be sorted by
> strongest RSSI first so that devices which are with a higher likelihood
> closer to us get their names resolved first. The kernel will also wait
> a
> few seconds (2 sounds like an ok value?) if user space hasn't yet

Do we really need to wait here? - if this is to allow human interaction
then 2 sec will be not enough anyway, if this is to allow the ack for
the last ( the assumption is that the user will decide whether to ack or
not on more or less sequential way ) discovered device, then,
2 sec is an overkill, so 1 or even 0.5 I think may be enough.

> responded with a name confirmation for a device when inquiry finishes.
> Once the list of names to be resolved is empty the device discovery is
> deemed complete.
> 
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Regards, 
Ilia

Re: Implementation of name-resolve procedures in mgmtops

[Johan Hedberg]

Hi Ilia,

On Tue, Nov 01, 2011, Ilia, Kolominsky wrote:
> Maybe we should keep resolve_name() method, so the user will be able to
> perform name resolution for a specific device without
> triggering the whole discovery process? This will allow more flexibility
> for the user.

We haven't had that in the higher level (D-Bus API) so far and it's not
planned to be added for 5.x either. The name gets refreshed
automatically every time there's a connection to the device without the
need of an explicit API for it.

> > Each "unknown name" device that user-space tells the kernel about gets
> > added to a list and once the currently ongoing inquiry finishes the
> > kernel proceeds with trying to resolve the name for each device in the
> > list, one at a time. For efficiency, this list should be sorted by
> > strongest RSSI first so that devices which are with a higher likelihood
> > closer to us get their names resolved first. The kernel will also wait
> > a
> > few seconds (2 sounds like an ok value?) if user space hasn't yet
> 
> Do we really need to wait here? - if this is to allow human interaction
> then 2 sec will be not enough anyway, if this is to allow the ack for
> the last ( the assumption is that the user will decide whether to ack or
> not on more or less sequential way ) discovered device, then,
> 2 sec is an overkill, so 1 or even 0.5 I think may be enough.

It's for the later case (e.g. for inquiry results that come right before
the inquiry complete event). The question then is, for a system under
heavy load what is a reasonable expectation to schedule in bluetoothd,
let it respond to the event and send the command and then schedule the
part of the kernel that handles the command from from bluetoothd. Maybe
1 second is enough, but there really isn't any single right answer for
this.

Johan

Re: Implementation of name-resolve procedures in mgmtops

[Johan Hedberg]

Hi,

On Tue, Nov 01, 2011, Johan Hedberg wrote:
> > > Each "unknown name" device that user-space tells the kernel about gets
> > > added to a list and once the currently ongoing inquiry finishes the
> > > kernel proceeds with trying to resolve the name for each device in the
> > > list, one at a time. For efficiency, this list should be sorted by
> > > strongest RSSI first so that devices which are with a higher likelihood
> > > closer to us get their names resolved first. The kernel will also wait
> > > a
> > > few seconds (2 sounds like an ok value?) if user space hasn't yet
> > 
> > Do we really need to wait here? - if this is to allow human interaction
> > then 2 sec will be not enough anyway, if this is to allow the ack for
> > the last ( the assumption is that the user will decide whether to ack or
> > not on more or less sequential way ) discovered device, then,
> > 2 sec is an overkill, so 1 or even 0.5 I think may be enough.
> 
> It's for the later case (e.g. for inquiry results that come right before
> the inquiry complete event). The question then is, for a system under
> heavy load what is a reasonable expectation to schedule in bluetoothd,
> let it respond to the event and send the command and then schedule the
> part of the kernel that handles the command from from bluetoothd. Maybe
> 1 second is enough, but there really isn't any single right answer for
> this.

Actually there are two more context switches involved which probably
introduce the most latency into the whole procedure: each time
bluetoothd gets a device_found event with confirm_name set to 1 it'll
need to access the file-system in /var/lib/bluetooth to check if the
name is stored there.

Johan

RE: Implementation of name-resolve procedures in mgmtops

[Ilia, Kolominsky]

> -----Original Message-----
> From: Johan Hedberg [mailto:johan.hedberg@gmail.com]
> Sent: Tuesday, November 01, 2011 3:52 PM
> To: Ilia, Kolominsky; linux-bluetooth@vger.kernel.org
> Subject: Re: Implementation of name-resolve procedures in mgmtops
> 
> Hi,
> 
> On Tue, Nov 01, 2011, Johan Hedberg wrote:
> > > > Each "unknown name" device that user-space tells the kernel about
> gets
> > > > added to a list and once the currently ongoing inquiry finishes
> the
> > > > kernel proceeds with trying to resolve the name for each device
> in the
> > > > list, one at a time. For efficiency, this list should be sorted
> by
> > > > strongest RSSI first so that devices which are with a higher
> likelihood
> > > > closer to us get their names resolved first. The kernel will also
> wait
> > > > a
> > > > few seconds (2 sounds like an ok value?) if user space hasn't yet
> > >
> > > Do we really need to wait here? - if this is to allow human
> interaction
> > > then 2 sec will be not enough anyway, if this is to allow the ack
> for
> > > the last ( the assumption is that the user will decide whether to
> ack or
> > > not on more or less sequential way ) discovered device, then,
> > > 2 sec is an overkill, so 1 or even 0.5 I think may be enough.
> >
> > It's for the later case (e.g. for inquiry results that come right
> before
> > the inquiry complete event). The question then is, for a system under
> > heavy load what is a reasonable expectation to schedule in
> bluetoothd,
> > let it respond to the event and send the command and then schedule
> the
> > part of the kernel that handles the command from from bluetoothd.
> Maybe
> > 1 second is enough, but there really isn't any single right answer
> for
> > this.
> 
> Actually there are two more context switches involved which probably
> introduce the most latency into the whole procedure: each time
> bluetoothd gets a device_found event with confirm_name set to 1 it'll
> need to access the file-system in /var/lib/bluetooth to check if the
> name is stored there.

Alright then, to be on the safe, let's do it 2 sec, my idea was
to finish the whole process asap. But since io is involved, 2 sec
seems to be a reasonable balance.
> 
> Johan

Ilia

RE: Implementation of name-resolve procedures in mgmtops

[Ganir, Chen]

Ilia, Johan,

> >
> > Actually there are two more context switches involved which probably
> > introduce the most latency into the whole procedure: each time
> > bluetoothd gets a device_found event with confirm_name set to 1 it'll
> > need to access the file-system in /var/lib/bluetooth to check if the
> > name is stored there.
> 
> Alright then, to be on the safe, let's do it 2 sec, my idea was
> to finish the whole process asap. But since io is involved, 2 sec
> seems to be a reasonable balance.
> >
> > Johan
> 

Please keep in mind that if you do it 2 seconds, that will cause a problem. In interleaved scanning, we need to scan for BR/EDR devices for ~5 seconds ( T_GAP_100/2), and then LE devices for 5 seconds. If we wait 2 seconds for timeout, this means 2 seconds in which we do nothing. This will mean that we need to scan for BR/EDR for 1 second, wait 2 seconds for ack, and then we will have about 2 more seconds for name requests for legacy devices. We need to think of a better solution here, which will coexist with interleaved device discovery.

What if we start name requests immediately after the inquiry is complete, according to what is already pending for name request (what the user has already confirmed for name request), and allow the user to confirm the name request for more devices up until we complete the name request process and return the SCAN_COMPLETE event ? The SCAN_COMPLETE event will be sent once the pending names list is clear, or any other limit we decide.

Chen Ganir.

Re: Implementation of name-resolve procedures in mgmtops

[Luiz Augusto von Dentz]

Hi All,

On Tue, Nov 1, 2011 at 4:11 PM, Ganir, Chen <chen.ganir@ti.com> wrote:
> Ilia, Johan,
>
>> >
>> > Actually there are two more context switches involved which probably
>> > introduce the most latency into the whole procedure: each time
>> > bluetoothd gets a device_found event with confirm_name set to 1 it'll
>> > need to access the file-system in /var/lib/bluetooth to check if the
>> > name is stored there.
>>
>> Alright then, to be on the safe, let's do it 2 sec, my idea was
>> to finish the whole process asap. But since io is involved, 2 sec
>> seems to be a reasonable balance.
>> >
>> > Johan
>>
>
> Please keep in mind that if you do it 2 seconds, that will cause a problem. In interleaved scanning, we need to scan for BR/EDR devices for ~5 seconds ( T_GAP_100/2), and then LE devices for 5 seconds. If we wait 2 seconds for timeout, this means 2 seconds in which we do nothing. This will mean that we need to scan for BR/EDR for 1 second, wait 2 seconds for ack, and then we will have about 2 more seconds for name requests for legacy devices. We need to think of a better solution here, which will coexist with interleaved device discovery.

I guess we can tweak the page timeout as someone suggested in the
meeting, anyway I have a feeling interleaved might change in the
future, IMO the interval is big enough to annoy people.

> What if we start name requests immediately after the inquiry is complete, according to what is already pending for name request (what the user has already confirmed for name request), and allow the user to confirm the name request for more devices up until we complete the name request process and return the SCAN_COMPLETE event ? The SCAN_COMPLETE event will be sent once the pending names list is clear, or any other limit we decide.

You mean in parallel with LE scan? I don't think this is possible
since name request involve paging so the baseband should be busy.

-- 
Luiz Augusto von Dentz

Re: Implementation of name-resolve procedures in mgmtops

[Johan Hedberg]

Hi Chen,

On Tue, Nov 01, 2011, Ganir, Chen wrote:
> Please keep in mind that if you do it 2 seconds, that will cause a
> problem. In interleaved scanning, we need to scan for BR/EDR devices
> for ~5 seconds ( T_GAP_100/2), and then LE devices for 5 seconds. If
> we wait 2 seconds for timeout, this means 2 seconds in which we do
> nothing. This will mean that we need to scan for BR/EDR for 1 second,
> wait 2 seconds for ack, and then we will have about 2 more seconds for
> name requests for legacy devices. We need to think of a better
> solution here, which will coexist with interleaved device discovery.

There must be something wrong with the spec or your understanding of it
since this doesn't make any sense to me. The only thing that would make
sense to me is if this 5 seconds only includes the inquiry phase but not
the name resolving phase. Typically BR/EDR devices have their page
timeout configured anywhere between 5 and 20 seconds. This means that
for a single BR/EDR device that happens to be out of range when the time
for name resolving comes, you could end up waiting quite long after the
inquiry phase. Even for devices within range 1 second isn't an unusual
time for name resolving, so you'd already go over 5 seconds with just 5
pre-2.1 devices around you.

> What if we start name requests immediately after the inquiry is
> complete, according to what is already pending for name request (what
> the user has already confirmed for name request), and allow the user
> to confirm the name request for more devices up until we complete the
> name request process and return the SCAN_COMPLETE event?

I don't know what you mean by "SCAN_COMPLETE" event, but this is what we
can and should certainly do. However if there was a single device found
for which we do not know the name, then the "pending" list will be empty
and in the worst case we'll end up waiting for whatever we decide to use
as a timeout. Note that this is not something that will always or even
frequently happen. In most cases inquiry results come well before the
inquiry complete and if the system isn't under really heavy load the
kernel will receive its ack in much shorter time.

Johan

RE: Implementation of name-resolve procedures in mgmtops

[Ganir, Chen]

Ilia, Johan,

> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> owner@vger.kernel.org] On Behalf Of Ilia, Kolominsky
> Sent: Tuesday, November 01, 2011 3:58 PM
> To: Johan Hedberg; linux-bluetooth@vger.kernel.org
> Subject: RE: Implementation of name-resolve procedures in mgmtops
> 
> > -----Original Message-----
> > From: Johan Hedberg [mailto:johan.hedberg@gmail.com]
> > Sent: Tuesday, November 01, 2011 3:52 PM
> > To: Ilia, Kolominsky; linux-bluetooth@vger.kernel.org
> > Subject: Re: Implementation of name-resolve procedures in mgmtops
> >
> > Hi,
> >
> > On Tue, Nov 01, 2011, Johan Hedberg wrote:
> > > > > Each "unknown name" device that user-space tells the kernel
> about
> > gets
> > > > > added to a list and once the currently ongoing inquiry finishes
> > the
> > > > > kernel proceeds with trying to resolve the name for each device
> > in the
> > > > > list, one at a time. For efficiency, this list should be sorted
> > by
> > > > > strongest RSSI first so that devices which are with a higher
> > likelihood
> > > > > closer to us get their names resolved first. The kernel will
> also
> > wait
> > > > > a
> > > > > few seconds (2 sounds like an ok value?) if user space hasn't
> yet
> > > >
> > > > Do we really need to wait here? - if this is to allow human
> > interaction
> > > > then 2 sec will be not enough anyway, if this is to allow the ack
> > for
> > > > the last ( the assumption is that the user will decide whether to
> > ack or
> > > > not on more or less sequential way ) discovered device, then,
> > > > 2 sec is an overkill, so 1 or even 0.5 I think may be enough.
> > >
> > > It's for the later case (e.g. for inquiry results that come right
> > before
> > > the inquiry complete event). The question then is, for a system
> under
> > > heavy load what is a reasonable expectation to schedule in
> > bluetoothd,
> > > let it respond to the event and send the command and then schedule
> > the
> > > part of the kernel that handles the command from from bluetoothd.
> > Maybe
> > > 1 second is enough, but there really isn't any single right answer
> > for
> > > this.
> >
> > Actually there are two more context switches involved which probably
> > introduce the most latency into the whole procedure: each time
> > bluetoothd gets a device_found event with confirm_name set to 1 it'll
> > need to access the file-system in /var/lib/bluetooth to check if the
> > name is stored there.
> 
> Alright then, to be on the safe, let's do it 2 sec, my idea was
> to finish the whole process asap. But since io is involved, 2 sec
> seems to be a reasonable balance.
> >
> > Johan
> 
> Ilia

Please keep in mind that if you do it 2 seconds, that will cause a problem. In interleaved scanning, we need to scan for BR/EDR devices for ~5 seconds ( T_GAP_100/2), and then LE devices for 5 seconds. If we wait 2 seconds for timeout, this means 2 seconds in which we do nothing. This will mean that we need to scan for BR/EDR for 1 second, wait 2 seconds for ack, and then we will have about 2 more seconds for name requests for legacy devices. We need to think of a better solution here, which will coexist with interleaved device discovery.

What if we start name requests immediately after the inquiry is complete, according to what is already pending for name request (what the user has already confirmed for name request), and allow the user to confirm the name request for more devices up until we complete the name request process and return the SCAN_COMPLETE event ? The SCAN_COMPLETE event will be sent once the pending names list is clear, or any other limit we decide.

Chen Ganir.

RE: Implementation of name-resolve procedures in mgmtops

[Ilia, Kolominsky]

> -----Original Message-----
> From: Ganir, Chen
> Sent: Tuesday, November 01, 2011 5:01 PM
> To: Ilia, Kolominsky; Johan Hedberg; linux-bluetooth@vger.kernel.org
> Subject: RE: Implementation of name-resolve procedures in mgmtops
> 
> Ilia, Johan,
> 
> > -----Original Message-----
> > From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> > owner@vger.kernel.org] On Behalf Of Ilia, Kolominsky
> > Sent: Tuesday, November 01, 2011 3:58 PM
> > To: Johan Hedberg; linux-bluetooth@vger.kernel.org
> > Subject: RE: Implementation of name-resolve procedures in mgmtops
> >
> > > -----Original Message-----
> > > From: Johan Hedberg [mailto:johan.hedberg@gmail.com]
> > > Sent: Tuesday, November 01, 2011 3:52 PM
> > > To: Ilia, Kolominsky; linux-bluetooth@vger.kernel.org
> > > Subject: Re: Implementation of name-resolve procedures in mgmtops
> > >
> > > Hi,
> > >
> > > On Tue, Nov 01, 2011, Johan Hedberg wrote:
> > > > > > Each "unknown name" device that user-space tells the kernel
> > about
> > > gets
> > > > > > added to a list and once the currently ongoing inquiry
> finishes
> > > the
> > > > > > kernel proceeds with trying to resolve the name for each
> device
> > > in the
> > > > > > list, one at a time. For efficiency, this list should be
> sorted
> > > by
> > > > > > strongest RSSI first so that devices which are with a higher
> > > likelihood
> > > > > > closer to us get their names resolved first. The kernel will
> > also
> > > wait
> > > > > > a
> > > > > > few seconds (2 sounds like an ok value?) if user space hasn't
> > yet
> > > > >
> > > > > Do we really need to wait here? - if this is to allow human
> > > interaction
> > > > > then 2 sec will be not enough anyway, if this is to allow the
> ack
> > > for
> > > > > the last ( the assumption is that the user will decide whether
> to
> > > ack or
> > > > > not on more or less sequential way ) discovered device, then,
> > > > > 2 sec is an overkill, so 1 or even 0.5 I think may be enough.
> > > >
> > > > It's for the later case (e.g. for inquiry results that come right
> > > before
> > > > the inquiry complete event). The question then is, for a system
> > under
> > > > heavy load what is a reasonable expectation to schedule in
> > > bluetoothd,
> > > > let it respond to the event and send the command and then
> schedule
> > > the
> > > > part of the kernel that handles the command from from bluetoothd.
> > > Maybe
> > > > 1 second is enough, but there really isn't any single right
> answer
> > > for
> > > > this.
> > >
> > > Actually there are two more context switches involved which
> probably
> > > introduce the most latency into the whole procedure: each time
> > > bluetoothd gets a device_found event with confirm_name set to 1
> it'll
> > > need to access the file-system in /var/lib/bluetooth to check if
> the
> > > name is stored there.
> >
> > Alright then, to be on the safe, let's do it 2 sec, my idea was
> > to finish the whole process asap. But since io is involved, 2 sec
> > seems to be a reasonable balance.
> > >
> > > Johan
> >
> > Ilia
> 
> Please keep in mind that if you do it 2 seconds, that will cause a
> problem. In interleaved scanning, we need to scan for BR/EDR devices
> for ~5 seconds ( T_GAP_100/2), and then LE devices for 5 seconds. If we
> wait 2 seconds for timeout, this means 2 seconds in which we do
> nothing. This will mean that we need to scan for BR/EDR for 1 second,
> wait 2 seconds for ack, and then we will have about 2 more seconds for
> name requests for legacy devices. We need to think of a better solution
> here, which will coexist with interleaved device discovery.
> 
> What if we start name requests immediately after the inquiry is
> complete, according to what is already pending for name request (what
> the user has already confirmed for name request), and allow the user to
> confirm the name request for more devices up until we complete the name
> request process and return the SCAN_COMPLETE event ? The SCAN_COMPLETE
> event will be sent once the pending names list is clear, or any other
> limit we decide.
> 

Lets send the he name-resolving requests after the "General Discovery
Procedure" ( as in 13.2.1 of spec ) completes?

> Chen Ganir.

Regards, Ilia