Re: [RFC v2 2/2] eal: add high-performance timer facility

[Stephen Hemminger <stephen@networkplumber.org>]

On Wed, 15 Mar 2023 18:03:42 +0100
Mattias Rönnblom <mattias.ronnblom@ericsson.com> wrote:

> The htimer library attempts at providing a timer facility with roughly
> the same functionality, but less overhead and better scalability than
> DPDK timer library.
> 
> The htimer library employs per-lcore hierarchical timer wheels and a
> message-based synchronization/MT-safety scheme.
> 
> RFC v2:
>  * Fix spelling.
>  * Fix signed/unsigned comparisons and discontinue the use of name-less
>    function parameters, both of which may result in compiler warnings.
>  * Undo the accidental removal of the bitset tests from the 'fast_tests'.
>  * Add a number of missing include files, causing build failures
>    (e.g., on AArch64 builds).
>  * Add perf test attempting to compare rte_timer, rte_htimer and rte_htw.
>  * Use nanoseconds (instead of TSC) as the default time unit.
>  * add() and manage() has flags which allows the caller to specify the
>    time unit (nanoseconds, TSC, or ticks) for the times provided.
> 
> Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>

Initial reactions.

Good:
  - timer API does need work
  - the units and API's model seems good, would have to look at real applications
  - tests look good as well.

Bad:
  - why do we need a new timer infrastructure. Could this not be done
    by extending and embracing the existing rte_timer() API's.
  - having fast rte_timer() would make existing app's faster.
  

PS:
  - ok to drop all the rte_alt_timer stuff, don't think any application depends on it.
    my survey of github projects, only one usage (OpenDataplane).



  -