On Tue, 2 Jun 2026 at 12:47, Morten Brørup <[email protected]> wrote: > > > From: Bruce Richardson [mailto:[email protected]] > > Sent: Tuesday, 2 June 2026 11.09 > > > > We can enable the building of the HPET code by default on Linux, since > > the timers are not used - or even initialized - by default. Instead an > > app needs to explicitly call rte_eal_hpet_init() to use the HPET timer > > APIs. Therefore, let's simplify the user experience by deprecating the > > option "use_hpet" and make it a no-op. > > > > To avoid issue with the dpdk-test binary which was trying to initialize > > the hpet on startup, move the hpet init call to the timer autotest - > > the > > only place where it was used. > > > > Signed-off-by: Bruce Richardson <[email protected]> > > --- > > Careful! > I think this patch has unintended side effects: > > On Linux, it unconditionally enables HPET (and sets RTE_LIBEAL_USE_HPET), > which was previously disabled by default. > > So, if some Linux applications use #ifdef RTE_LIBEAL_USE_HPET, they will now > tell DPDK to use that timer instead of the TSC. > We can fix the apps/examples in the DPDK repo, but it will potentially change > behavior of DPDK user's applications. > > I'm not opposed to unconditionally enabling HPET ability in DPDK itself on > Linux. > But I'm worried about side effects of unconditionally enabling #ifdef > RTE_LIBEAL_USE_HPET in Linux user applications.
I don't see a functional impact. There may be an impact on performance? But users can switch to rte_get_tsc_cycles() to avoid the added branch. On the other hand, did you consider dropping HPET altogether? -- David Marchand
