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

[Bruce Richardson <bruce.richardson@intel.com>]

On Tue, Jun 02, 2026 at 01:39:42PM +0200, David Marchand wrote:
> On Tue, 2 Jun 2026 at 12:47, Morten Brørup <mb@smartsharesystems.com> wrote:
> >
> > > 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.
> 
> 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.
> 

I'd be very surprised if there was an impact from that. Any timers we have
already take a measurable number of cycles, so the extra branch is going to
be unnoticable IMHO.

> 
> On the other hand, did you consider dropping HPET altogether?
> 

I did, but that I considered a bit riskier and harder to do, as we don't
know who might actually be using it. This was a simple way to get rid of
the unnecessary option without impacting apps.

IIRC the main reason we had HPET off by default was that lots of distro
kernels in the past had the necessary MMAP_HPET support disabled by
default, making it awkward to use - the user had to compile the kernel.
However, I was pleasantly surprised to discover that Ubuntu has it enabled
by default so the HPET now works out of the box, and it's interesting to
see the timer_autotest doing TSC and HPET clock comparisons.

/Bruce