[RFC v2 0/2] Add high-performance timer facility

[Mattias Rönnblom]

On 2024-10-03 23:32, Morten Brørup wrote:
>> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
>> Sent: Thursday, 3 October 2024 20.37
>>
>> On Wed, 15 Mar 2023 18:03:40 +0100
>> Mattias Rönnblom <mattias.ronnblom at ericsson.com> wrote:
>>
>>> This patchset is an attempt to introduce a high-performance, highly
>>> scalable timer facility into DPDK.
>>>
>>> More specifically, the goals for the htimer library are:
>>>
>>> * Efficient handling of a handful up to hundreds of thousands of
>>>    concurrent timers.
>>> * Make adding and canceling timers low-overhead, constant-time
>>>    operations.
>>> * Provide a service functionally equivalent to that of
>>>    <rte_timer.h>. API/ABI backward compatibility is secondary.
>>
>> Worthwhile goals, and the problem needs to be addressed.
>> But this patch never got accepted.
> 
> I think work on it was put on hold due to the requested changes requiring a significant development effort.
> I too look forward to work on this being resumed. ;-)
> 
>>
>> Please fix/improve/extend existing rte_timer instead.
> 
> The rte_timer API is too "fat" for use in the fast path with millions of timers, e.g. TCP flow timers.
> 
> Shoehorning a fast path feature into a slow path API is not going to cut it. I support having a separate htimer library with its own API for high volume, high-performance fast path timers.
> 
> When striving for low latency across the internet, timing is everything. Packet pacing is the "new" hot thing in congestion control algorithms, and a simple software implementation would require a timer firing once per packet.
> 

I think DPDK should have two public APIs in the timer area. One is a 
just a bare-bones hierarchical timer wheel API, without callbacks, 
auto-created per-lcore instances, MT safety or any other of the 
<rte_timer.h> bells and whistles. It also doesn't make any assumptions 
about the time source (other it being monotonic) or resolution.

The other is a new variant of <rte_timer.h>, using the core HTW library 
for its implementation (and being public, it may also expose this 
library in its header files, which may be required for efficient 
operation). The new <rte_timer.h> would provide the same kind of 
functionality as the old API, but with some quirks and bugs fixed, plus 
potentially some new functionality added. For example, it would be 
useful to allow non-preemption safe threads to add and remove timers 
(something rte_timer and its spinlocks doesn't allow).

I would consider both "fast path APIs".

In addition, there should probably also be a time source API.

Considering the lead time of relatively small contributions like the 
bitops extensions and the new bitset API (which still aren't in), I 
can't imagine how long time it would take to get in a semi-backward 
compatible rte_timer with a new implementation, plus a new timer wheel 
library, into DPDK.