Hi Luiz,

On Monday 18 of April 2016 18:16:00 Luiz Augusto von Dentz wrote:

From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com>

Following the discussion about the Timer API I decided to prototype the
feature in the Bluetooth subsystem:

XX:XX:XX:XX:XX:XX (public)> security 2
bt: bt_timer_queue_add (0x0011a54c): tq 0x00119940 t 0x0011bb1c ticks 3000
XX:XX:XX:XX:XX:XX (public)> bt: timer_queue_fiber (0x0011994c): tq
0x00119940 thread_id 1153356 started bt: timer_queue_ticks_remains
(0x0011994c): tq 0x00119940 ticks 3000 bt: bt_timer_queue_cancel
(0x0011dc60): tq 0x00119940 t 0x0011bb1c bt: bt_timer_queue_add
(0x0011dc60): tq 0x00119940 t 0x0011bb1c ticks 3000 bt:
timer_queue_ticks_remains (0x0011994c): tq 0x00119940 ticks 3000 bt:
bt_timer_queue_cancel (0x0011dc60): tq 0x00119940 t 0x0011bb1c bt:
bt_timer_queue_add (0x0011dc60): tq 0x00119940 t 0x0011bb1c ticks 3000 bt:
timer_queue_ticks_remains (0x0011994c): tq 0x00119940 ticks 2990 Confirm
passkey for XX:XX:XX:XX:XX:XX (public): 775621
bt: timer_expired (0x0011994c): t 0x0011bb1c
bt: smp_timeout: SMP Timeout
bt: timer_queue_ticks_remains (0x0011994c): tq 0x00119940 ticks 0
bt: timer_queue_fiber (0x0011994c): tq 0x00119940 thread_id 1153356 stopped
Disconnected: XX:XX:XX:XX:XX:XX (public) (reason 19)

So at this point it works properly, I tested what could be the minimal stack
necessary in order to run the timer queue and arrive at 512 bytes which is
4 times bigger than what we used to have when using a delayed fiber in SMP
so the timer API only really payoff in terms of memory in case there is 4
or more timer active, which there will be since we will be adding more user
for that in ATT and L2CAP protocols.

I don't get this why you need 512bytes if only 128 was needed by SMP. This
should mostly depend on how heavy is the callback, right? Is overhead for
queue that big?

Ive also make the timer queue abort if there is no timers left, this is
something that perhaps is not such a good idea if there is too much
overhead starting the fibers on demand, perhaps by the it cannot be used if
the ticks are low perhaps it is shorter then starting a fiber thus loosing
precision. Anyway the idea here is not to invent a high precision timer, in
fact later on we may introduce a function that takes the timeout in seconds
instead of ticks and then coalesce multiple timers that would happen in the
same second thus reducing the amount of wakeups.

Luiz Augusto von Dentz (3):
Bluetooth: Add timer API
Bluetooth: Kconfig: Add BLUETOOTH_DEBUG_TIMER
Bluetooth: SMP: Make use of bt_timer API

net/bluetooth/Kconfig | 17 ++++
net/bluetooth/Makefile | 1 +
net/bluetooth/smp.c | 40 ++++-----
net/bluetooth/timer.c | 216
+++++++++++++++++++++++++++++++++++++++++++++++++ net/bluetooth/timer.h |
48 +++++++++++
5 files changed, 299 insertions(+), 23 deletions(-)
create mode 100644 net/bluetooth/timer.c
create mode 100644 net/bluetooth/timer.h

--
BR
Szymon Janc