[RFC v2 0/2] Add high-performance timer facility
Morten Brørup
mb at smartsharesystems.com
Thu Oct 3 23:32:41 CEST 2024
> 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.
More information about the dev
mailing list