1.. SPDX-License-Identifier: BSD-3-Clause 2 Copyright(c) 2010-2014 Intel Corporation. 3 4Timer Library 5============= 6 7The Timer library provides a timer service to DPDK execution units to enable execution of callback functions asynchronously. 8Features of the library are: 9 10* Timers can be periodic (multi-shot) or single (one-shot). 11 12* Timers can be loaded from one core and executed on another. It has to be specified in the call to rte_timer_reset(). 13 14* Timers provide high precision (depends on the call frequency to rte_timer_manage() that checks timer expiration for the local core). 15 16* If not required in the application, timers can be disabled at compilation time by not calling the rte_timer_manage() to increase performance. 17 18The timer library uses the rte_get_timer_cycles() function that uses the High Precision Event Timer (HPET) 19or the CPUs Time Stamp Counter (TSC) to provide a reliable time reference. 20 21This library provides an interface to add, delete and restart a timer. The API is based on BSD callout() with a few differences. 22Refer to the `callout manual <http://www.daemon-systems.org/man/callout.9.html>`_. 23 24Implementation Details 25---------------------- 26 27Timers are tracked on a per-lcore basis, 28with all pending timers for a core being maintained in order of timer expiry in a skiplist data structure. 29The skiplist used has ten levels and each entry in the table appears in each level with probability ¼^level. 30This means that all entries are present in level 0, 1 in every 4 entries is present at level 1, 31one in every 16 at level 2 and so on up to level 9. 32This means that adding and removing entries from the timer list for a core can be done in log(n) time, 33up to 4^10 entries, that is, approximately 1,000,000 timers per lcore. 34 35A timer structure contains a special field called status, 36which is a union of a timer state (stopped, pending, running, config) and an owner (lcore id). 37Depending on the timer state, we know if a timer is present in a list or not: 38 39* STOPPED: no owner, not in a list 40 41* CONFIG: owned by a core, must not be modified by another core, maybe in a list or not, depending on previous state 42 43* PENDING: owned by a core, present in a list 44 45* RUNNING: owned by a core, must not be modified by another core, present in a list 46 47Resetting or stopping a timer while it is in a CONFIG or RUNNING state is not allowed. 48When modifying the state of a timer, 49a Compare And Swap instruction should be used to guarantee that the status (state+owner) is modified atomically. 50 51Inside the rte_timer_manage() function, 52the skiplist is used as a regular list by iterating along the level 0 list, which contains all timer entries, 53until an entry which has not yet expired has been encountered. 54To improve performance in the case where there are entries in the timer list but none of those timers have yet expired, 55the expiry time of the first list entry is maintained within the per-core timer list structure itself. 56On 64-bit platforms, this value can be checked without the need to take a lock on the overall structure. 57(Since expiry times are maintained as 64-bit values, 58a check on the value cannot be done on 32-bit platforms without using either a compare-and-swap (CAS) instruction or using a lock, 59so this additional check is skipped in favor of checking as normal once the lock has been taken.) 60On both 64-bit and 32-bit platforms, 61a call to rte_timer_manage() returns without taking a lock in the case where the timer list for the calling core is empty. 62 63Use Cases 64--------- 65 66The timer library is used for periodic calls, such as garbage collectors, or some state machines (ARP, bridging, and so on). 67 68References 69---------- 70 71* `callout manual <http://www.daemon-systems.org/man/callout.9.html>`_ 72 - The callout facility that provides timers with a mechanism to execute a function at a given time. 73 74* `HPET <http://en.wikipedia.org/wiki/HPET>`_ 75 - Information about the High Precision Event Timer (HPET). 76