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

["Morten Brørup" <mb@smartsharesystems.com>]

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