[RFC PATCH 0/3] remove unneeded build options

[RFC PATCH 0/3] remove unneeded build options

[Bruce Richardson]

Having unnecessary build options just makes things confusing for
the user, and expands the set of potential builds. This set
makes 3 build options no-ops, and marks them as deprecated for
future removal.

Bruce Richardson (3):
  build: deprecate kernel dir option
  build: deprecate standalone tests option
  build: deprecate HPET build option

 app/meson.build                      | 6 +-----
 app/test/test.c                      | 7 -------
 app/test/test_timer.c                | 5 +++++
 config/meson.build                   | 2 +-
 doc/guides/linux_gsg/enable_func.rst | 2 --
 doc/guides/rel_notes/deprecation.rst | 7 +++++++
 lib/eal/linux/meson.build            | 5 +----
 meson_options.txt                    | 6 +++---
 8 files changed, 18 insertions(+), 22 deletions(-)

--
2.53.0

[RFC PATCH 1/3] build: deprecate kernel dir option

[Bruce Richardson]

The kernel_dir option does nothing, so it can be deprecated and removed
in future.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 doc/guides/rel_notes/deprecation.rst | 4 ++++
 meson_options.txt                    | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 17f90a6352..ed1dda6008 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -17,6 +17,10 @@ Other API and ABI deprecation notices are to be posted below.
 Deprecation Notices
 -------------------
 
+* build: The following meson build options are deprecated and will be removed in a future release:
+
+  - ``kernel_dir``: option unused as Linux kernel drivers are in a separate ``dpdk-kmods`` repository.
+
 * kvargs: The function ``rte_kvargs_process`` will get a new parameter
   for returning key match count. It will ease handling of no-match case.
 
diff --git a/meson_options.txt b/meson_options.txt
index e28d24054c..7bd5ebc084 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -33,7 +33,7 @@ option('ibverbs_link', type: 'combo', choices : ['static', 'shared', 'dlopen'],
 option('include_subdir_arch', type: 'string', value: '', description:
        'subdirectory where to install arch-dependent headers')
 option('kernel_dir', type: 'string', value: '', description:
-       'Path to the kernel for building kernel modules. Headers must be in $kernel_dir or $kernel_dir/build. Modules will be installed in /lib/modules.')
+       '[Deprecated] Value unused. Previously, path to the kernel for building kernel modules.')
 option('machine', type: 'string', value: 'auto', description:
        'Alias of cpu_instruction_set.')
 option('max_ethports', type: 'integer', value: 32, description:
-- 
2.53.0

RE: [RFC PATCH 1/3] build: deprecate kernel dir option

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Tuesday, 2 June 2026 11.09
> 
> The kernel_dir option does nothing, so it can be deprecated and removed
> in future.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---

Good cleanup.
Acked-by: Morten Brørup <mb@smartsharesystems.com>

[RFC PATCH 2/3] build: deprecate standalone tests option

[Bruce Richardson]

The unit tests can be disabled in DPDK in a couple of ways. Firstly,
there is the original "tests" boolean option - when set to false, the
tests are skipped as part of the build. However, the newer
enable_apps/disable_apps options also can be used to disable the tests
[you can disable using the "enable" option by omitting "tests" from the
list to enable].

This duplication of functionality is unnecessary, so let's remove the
standalone tests option.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 app/meson.build                      | 6 +-----
 doc/guides/rel_notes/deprecation.rst | 1 +
 meson_options.txt                    | 2 +-
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/app/meson.build b/app/meson.build
index 1798db3ae4..52f704ec94 100644
--- a/app/meson.build
+++ b/app/meson.build
@@ -17,6 +17,7 @@ apps = [
         'graph',
         'pdump',
         'proc-info',
+        'test',
         'test-acl',
         'test-bbdev',
         'test-cmdline',
@@ -35,11 +36,6 @@ apps = [
         'test-security-perf',
 ]
 
-if get_option('tests')
-# build the auto test app if enabled.
-    apps += 'test'
-endif
-
 default_cflags = machine_args + ['-DALLOW_EXPERIMENTAL_API']
 default_ldflags = []
 if get_option('default_library') == 'static' and not is_windows
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index ed1dda6008..15459851d0 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -20,6 +20,7 @@ Deprecation Notices
 * build: The following meson build options are deprecated and will be removed in a future release:
 
   - ``kernel_dir``: option unused as Linux kernel drivers are in a separate ``dpdk-kmods`` repository.
+  - ``tests``: disabling tests can be achieved by using the ``enable_apps`` / ``disable_apps`` options instead.
 
 * kvargs: The function ``rte_kvargs_process`` will get a new parameter
   for returning key match count. It will ease handling of no-match case.
diff --git a/meson_options.txt b/meson_options.txt
index 7bd5ebc084..323a3901e1 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -55,6 +55,6 @@ option('enable_stdatomic', type: 'boolean', value: false, description:
 option('enable_trace_fp', type: 'boolean', value: false, description:
        'enable fast path trace points.')
 option('tests', type: 'boolean', value: true, description:
-       'build unit tests')
+       '[Deprecated] Value unused. Add "tests" to disable_apps setting to disable the unit tests')
 option('use_hpet', type: 'boolean', value: false, description:
        'use HPET timer in EAL')
-- 
2.53.0

RE: [RFC PATCH 2/3] build: deprecate standalone tests option

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Tuesday, 2 June 2026 11.09
> 
> The unit tests can be disabled in DPDK in a couple of ways. Firstly,
> there is the original "tests" boolean option - when set to false, the
> tests are skipped as part of the build. However, the newer
> enable_apps/disable_apps options also can be used to disable the tests
> [you can disable using the "enable" option by omitting "tests" from the
> list to enable].
> 
> This duplication of functionality is unnecessary, so let's remove the
> standalone tests option.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---

Good cleanup.
Acked-by: Morten Brørup <mb@smartsharesystems.com>

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

[Bruce Richardson]

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>
---
 app/test/test.c                      | 7 -------
 app/test/test_timer.c                | 5 +++++
 config/meson.build                   | 2 +-
 doc/guides/linux_gsg/enable_func.rst | 2 --
 doc/guides/rel_notes/deprecation.rst | 2 ++
 lib/eal/linux/meson.build            | 5 +----
 meson_options.txt                    | 2 +-
 7 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/app/test/test.c b/app/test/test.c
index 58ef52f312..99d6e90f8b 100644
--- a/app/test/test.c
+++ b/app/test/test.c
@@ -180,13 +180,6 @@ main(int argc, char **argv)
 		goto out;
 	}
 
-#ifdef RTE_LIBEAL_USE_HPET
-	if (rte_eal_hpet_init(1) < 0)
-#endif
-		RTE_LOG(INFO, APP,
-				"HPET is not enabled, using TSC as default timer\n");
-
-
 	char *dpdk_test = getenv("DPDK_TEST");
 
 	if (dpdk_test && strlen(dpdk_test) > 0)
diff --git a/app/test/test_timer.c b/app/test/test_timer.c
index c936843ddc..dcb26c4395 100644
--- a/app/test/test_timer.c
+++ b/app/test/test_timer.c
@@ -501,6 +501,11 @@ static int
 timer_sanity_check(void)
 {
 #ifdef RTE_LIBEAL_USE_HPET
+	if (rte_eal_hpet_init(1) < 0) {
+		printf("HPET is not enabled, using TSC as default timer\n");
+		return 0;
+	}
+
 	if (eal_timer_source != EAL_TIMER_HPET) {
 		printf("Not using HPET, can't sanity check timer sources\n");
 		return 0;
diff --git a/config/meson.build b/config/meson.build
index 9ba7b9a338..6012a3c243 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -381,7 +381,7 @@ endforeach
 
 # set other values pulled from the build options
 dpdk_conf.set('RTE_MAX_ETHPORTS', get_option('max_ethports'))
-dpdk_conf.set('RTE_LIBEAL_USE_HPET', get_option('use_hpet'))
+dpdk_conf.set('RTE_LIBEAL_USE_HPET', is_linux)
 dpdk_conf.set('RTE_ENABLE_STDATOMIC', get_option('enable_stdatomic'))
 dpdk_conf.set('RTE_ENABLE_TRACE_FP', get_option('enable_trace_fp'))
 dpdk_conf.set('RTE_PKTMBUF_HEADROOM', get_option('pkt_mbuf_headroom'))
diff --git a/doc/guides/linux_gsg/enable_func.rst b/doc/guides/linux_gsg/enable_func.rst
index 4e1a939f35..1d5b030172 100644
--- a/doc/guides/linux_gsg/enable_func.rst
+++ b/doc/guides/linux_gsg/enable_func.rst
@@ -176,8 +176,6 @@ To enable HPET support in DPDK:
    Note that this may involve doing a kernel rebuild,
    as many common linux distributions do *not* have this setting
    enabled by default in their kernel builds.
-#. Enable DPDK support for HPET by using the build-time meson option ``use_hpet``,
-   for example, ``meson configure -Duse_hpet=true``
 
 For an application to use the ``rte_get_hpet_cycles()`` and ``rte_get_hpet_hz()`` API calls,
 and optionally to make the HPET the default time source for the rte_timer library,
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 15459851d0..42ad118c92 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -21,6 +21,8 @@ Deprecation Notices
 
   - ``kernel_dir``: option unused as Linux kernel drivers are in a separate ``dpdk-kmods`` repository.
   - ``tests``: disabling tests can be achieved by using the ``enable_apps`` / ``disable_apps`` options instead.
+  - ``use_hpet``: option unused as HPET is only supported on Linux
+    and is runtime-enabled using ``rte_eal_hpet_init()`` API.
 
 * kvargs: The function ``rte_kvargs_process`` will get a new parameter
   for returning key match count. It will ease handling of no-match case.
diff --git a/lib/eal/linux/meson.build b/lib/eal/linux/meson.build
index 29ba313218..8b0519c9a1 100644
--- a/lib/eal/linux/meson.build
+++ b/lib/eal/linux/meson.build
@@ -15,14 +15,11 @@ sources += files(
         'eal_memory.c',
         'eal_thread.c',
         'eal_timer.c',
+        'eal_timer_hpet.c',
         'eal_vfio.c',
         'eal_vfio_mp_sync.c',
 )
 
-if dpdk_conf.get('RTE_LIBEAL_USE_HPET')
-    sources += files('eal_timer_hpet.c')
-endif
-
 deps += ['kvargs', 'telemetry']
 if has_libnuma
     dpdk_conf.set10('RTE_EAL_NUMA_AWARE_HUGEPAGES', true)
diff --git a/meson_options.txt b/meson_options.txt
index 323a3901e1..242de6681f 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -57,4 +57,4 @@ option('enable_trace_fp', type: 'boolean', value: false, description:
 option('tests', type: 'boolean', value: true, description:
        '[Deprecated] Value unused. Add "tests" to disable_apps setting to disable the unit tests')
 option('use_hpet', type: 'boolean', value: false, description:
-       'use HPET timer in EAL')
+       '[Deprecated] Value unused. HPET can be runtime-enabled on Linux using rte_eal_hpet_init().')
-- 
2.53.0

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

[Morten Brørup]

> 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.

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

[David Marchand]

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.


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


-- 
David Marchand

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

[Bruce Richardson]

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

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

[Morten Brørup]

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

Google AI says that - on modern CPUs - the HPET has no advantages over the TSC.
This supports David's idea.

Suggestion:
Rewrite HPET APIs as a shim to TSC, and deprecate the HPET APIs.

-Morten

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

[Bruce Richardson]

On Tue, Jun 02, 2026 at 12:47:00PM +0200, Morten Brørup 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.
> 

Good point, I hadn't considered if end applications had code guarded by
USE_HPET.

However, even if HPET support is build-enabled, it still requires apps to
explicitly opt-in a) to use it and then b) to make it the default for timer
operations. That means that if apps have got the code present to use HPET
by default, then they must have a valid reason for doing so and have
explicitly opted in to doing so by adding the hpet API calls. It's not
possible for apps to "accidentally" start using HPET. [I suppose there may
be a risk from old/legacy code in apps, maybe where hpet was used in the
past and forgotten about, but otherwise I can't see there being an issue.]

More review and testing is welcome though, to ensure I'm not actually
missing something here...

/Bruce