> From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Thursday, 3 October 2024 20.37 > > On Wed, 15 Mar 2023 18:03:40 +0100 > Mattias Rönnblom <mattias.ronnb...@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.
