RE: [RFC PATCH 3/3] build: deprecate HPET build option

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

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> 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 <bruce.richardson@intel.com>
> ---

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.