[PATCH 0/3] manage net/null dependency for tests

[PATCH 0/3] manage net/null dependency for tests

[Bruce Richardson]

A number of unit tests take advantage of net_null driver to use
as a dummy packet source. When this driver is disabled we then get
tests failures in fast-tests. Fix these by recording the dependency
appropriately or by skipping test sections if the dependency isn't
present. The final patch is an optional extra - it marks the null
driver down to always be built.

Bruce Richardson (3):
  test/bpf: skip some testing if null net driver not present
  test: fix missing dependency on null networking driver
  drivers: always enable the null net driver [RFC]

 app/test/meson.build | 4 ++--
 app/test/test_bpf.c  | 9 +++++++++
 drivers/meson.build  | 2 ++
 3 files changed, 13 insertions(+), 2 deletions(-)

--
2.51.0

[PATCH 1/3] test/bpf: skip some testing if null net driver not present

[Bruce Richardson]

Some of the BPF tests require the net/null driver to be present, so skip
those tests if it's not found. If the early part of the tests fail,
return that failure - on if they succeed do we return skipped on the
missing dependency.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 app/test/test_bpf.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/app/test/test_bpf.c b/app/test/test_bpf.c
index a7d56f8d86..ae588acb16 100644
--- a/app/test/test_bpf.c
+++ b/app/test/test_bpf.c
@@ -3725,6 +3725,11 @@ test_bpf_elf_rx_load(void)
 	return ret == 0 ? TEST_SUCCESS : TEST_FAILED;
 }
 
+#ifdef RTE_NET_NULL
+static const bool have_net_null = true;
+#else
+static const bool have_net_null;  /* statics default to false */
+#endif
 
 static int
 test_bpf_elf(void)
@@ -3732,6 +3737,10 @@ test_bpf_elf(void)
 	int ret;
 
 	ret = test_bpf_elf_load();
+	if (ret == TEST_SUCCESS && !have_net_null) {
+		printf("net_null driver not available, skipping remainder of BPF tests\n");
+		return TEST_SKIPPED;
+	}
 	if (ret == TEST_SUCCESS)
 		ret = test_bpf_elf_tx_load();
 	if (ret == TEST_SUCCESS)
-- 
2.51.0

Re: [PATCH 1/3] test/bpf: skip some testing if null net driver not present

[Stephen Hemminger]

On Thu, 22 Jan 2026 12:23:51 +0000
Bruce Richardson <bruce.richardson@intel.com> wrote:

> Some of the BPF tests require the net/null driver to be present, so skip
> those tests if it's not found. If the early part of the tests fail,
> return that failure - on if they succeed do we return skipped on the
> missing dependency.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
>  app/test/test_bpf.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/app/test/test_bpf.c b/app/test/test_bpf.c
> index a7d56f8d86..ae588acb16 100644
> --- a/app/test/test_bpf.c
> +++ b/app/test/test_bpf.c
> @@ -3725,6 +3725,11 @@ test_bpf_elf_rx_load(void)
>  	return ret == 0 ? TEST_SUCCESS : TEST_FAILED;
>  }
>  
> +#ifdef RTE_NET_NULL
> +static const bool have_net_null = true;
> +#else
> +static const bool have_net_null;  /* statics default to false */
> +#endif
>  
>  static int
>  test_bpf_elf(void)
> @@ -3732,6 +3737,10 @@ test_bpf_elf(void)
>  	int ret;
>  
>  	ret = test_bpf_elf_load();
> +	if (ret == TEST_SUCCESS && !have_net_null) {
> +		printf("net_null driver not available, skipping remainder of BPF tests\n");
> +		return TEST_SKIPPED;
> +	}
>  	if (ret == TEST_SUCCESS)
>  		ret = test_bpf_elf_tx_load();
>  	if (ret == TEST_SUCCESS)

Only the tests doing ELF load need a device.
I think that part can be handled at compile time with the #ifdef
or by splitting the ELF load tests to another file and doing it with meson.build

Re: [PATCH 1/3] test/bpf: skip some testing if null net driver not present

[Bruce Richardson]

On Thu, Jan 22, 2026 at 08:19:48AM -0800, Stephen Hemminger wrote:
> On Thu, 22 Jan 2026 12:23:51 +0000
> Bruce Richardson <bruce.richardson@intel.com> wrote:
> 
> > Some of the BPF tests require the net/null driver to be present, so skip
> > those tests if it's not found. If the early part of the tests fail,
> > return that failure - on if they succeed do we return skipped on the
> > missing dependency.
> > 
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > ---
> >  app/test/test_bpf.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/app/test/test_bpf.c b/app/test/test_bpf.c
> > index a7d56f8d86..ae588acb16 100644
> > --- a/app/test/test_bpf.c
> > +++ b/app/test/test_bpf.c
> > @@ -3725,6 +3725,11 @@ test_bpf_elf_rx_load(void)
> >  	return ret == 0 ? TEST_SUCCESS : TEST_FAILED;
> >  }
> >  
> > +#ifdef RTE_NET_NULL
> > +static const bool have_net_null = true;
> > +#else
> > +static const bool have_net_null;  /* statics default to false */
> > +#endif
> >  
> >  static int
> >  test_bpf_elf(void)
> > @@ -3732,6 +3737,10 @@ test_bpf_elf(void)
> >  	int ret;
> >  
> >  	ret = test_bpf_elf_load();
> > +	if (ret == TEST_SUCCESS && !have_net_null) {
> > +		printf("net_null driver not available, skipping remainder of BPF tests\n");
> > +		return TEST_SKIPPED;
> > +	}
> >  	if (ret == TEST_SUCCESS)
> >  		ret = test_bpf_elf_tx_load();
> >  	if (ret == TEST_SUCCESS)
> 
> Only the tests doing ELF load need a device.
> I think that part can be handled at compile time with the #ifdef
> or by splitting the ELF load tests to another file and doing it with meson.build

We could do that using ifdefs, but it means adding ifdefs around lots of
code blocks as the compiler will complain about unused functions if we just
ifdef out the calls to them. That's why I took this approach, to have the
minimal possible ifdef. If we don't want to mark the test as skipped we can
just change it to return success immedately if we don't have the null
driver.

/Bruce

[PATCH] test/bpf: skip the BPF ELF load tests if net null missing

[Stephen Hemminger]

The BPF filtering tests need NULL PMD vdev to work.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 app/test/test_bpf.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/app/test/test_bpf.c b/app/test/test_bpf.c
index 0e969f9f13..78998c6194 100644
--- a/app/test/test_bpf.c
+++ b/app/test/test_bpf.c
@@ -3280,7 +3280,15 @@ test_bpf(void)
 
 REGISTER_FAST_TEST(bpf_autotest, NOHUGE_OK, ASAN_OK, test_bpf);
 
-#ifdef TEST_BPF_ELF_LOAD
+/*
+ * The BPF elf load tests needs the BPF programs to be successfully
+ * compiled into generated file bpf_test.h. This means having
+ * clang with BPF target and xxd command to encode object.
+ *
+ * Test also needs the NULL PMD to be able to have something
+ * to insert filter onto.
+ */
+#if defined(RTE_NET_NULL) && defined(TEST_BPF_ELF_LOAD)
 
 /*
  * Helper function to write BPF object data to temporary file.
@@ -3746,11 +3754,11 @@ test_bpf_elf(void)
 static int
 test_bpf_elf(void)
 {
-	printf("BPF compile not supported, skipping test\n");
+	printf("BPF compile or NULL PMD not supported, skipping test\n");
 	return TEST_SKIPPED;
 }
 
-#endif /* !TEST_BPF_ELF_LOAD */
+#endif /* !(TEST_BPF_ELF_LOAD && RTE_NULL) */
 
 REGISTER_FAST_TEST(bpf_elf_autotest, NOHUGE_OK, ASAN_OK, test_bpf_elf);
 
-- 
2.51.0

RE: [PATCH] test/bpf: skip the BPF ELF load tests if net null missing

[Morten Brørup]

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Thursday, 22 January 2026 23.17
> 
> The BPF filtering tests need NULL PMD vdev to work.
> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>

With or without suggested change,
Acked-by: Morten Brørup <mb@smartsharesystems.com>

> ---
>  app/test/test_bpf.c | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/app/test/test_bpf.c b/app/test/test_bpf.c
> index 0e969f9f13..78998c6194 100644
> --- a/app/test/test_bpf.c
> +++ b/app/test/test_bpf.c
> @@ -3280,7 +3280,15 @@ test_bpf(void)
> 
>  REGISTER_FAST_TEST(bpf_autotest, NOHUGE_OK, ASAN_OK, test_bpf);
> 
> -#ifdef TEST_BPF_ELF_LOAD
> +/*
> + * The BPF elf load tests needs the BPF programs to be successfully
> + * compiled into generated file bpf_test.h. This means having
> + * clang with BPF target and xxd command to encode object.
> + *
> + * Test also needs the NULL PMD to be able to have something
> + * to insert filter onto.
> + */
> +#if defined(RTE_NET_NULL) && defined(TEST_BPF_ELF_LOAD)

nit:
Consider swapping the order:
#if defined(TEST_BPF_ELF_LOAD) && defined(RTE_NET_NULL)

> 
>  /*
>   * Helper function to write BPF object data to temporary file.
> @@ -3746,11 +3754,11 @@ test_bpf_elf(void)
>  static int
>  test_bpf_elf(void)
>  {
> -	printf("BPF compile not supported, skipping test\n");
> +	printf("BPF compile or NULL PMD not supported, skipping test\n");
>  	return TEST_SKIPPED;
>  }
> 
> -#endif /* !TEST_BPF_ELF_LOAD */
> +#endif /* !(TEST_BPF_ELF_LOAD && RTE_NULL) */
> 
>  REGISTER_FAST_TEST(bpf_elf_autotest, NOHUGE_OK, ASAN_OK,
> test_bpf_elf);
> 
> --
> 2.51.0

Re: [PATCH] test/bpf: skip the BPF ELF load tests if net null missing

[David Marchand]

On Thu, 22 Jan 2026 at 23:17, Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> The BPF filtering tests need NULL PMD vdev to work.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>

Applied, thanks.


-- 
David Marchand

[PATCH 2/3] test: fix missing dependency on null networking driver

[Bruce Richardson]

The pcapng and vdev autotests depend upon the null networking driver in
order to run, so record that dependency in the meson file, so they are
skipped if it's not present.

Fixes: 50823f30f0c8 ("test: build using per-file dependencies")
Cc: stable@dpdk.org

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 app/test/meson.build | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app/test/meson.build b/app/test/meson.build
index f4d04a6e42..0195a31c95 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -135,7 +135,7 @@ source_file_deps = {
     'test_mp_secondary.c': ['hash'],
     'test_net_ether.c': ['net'],
     'test_net_ip6.c': ['net'],
-    'test_pcapng.c': ['ethdev', 'net', 'pcapng', 'bus_vdev'],
+    'test_pcapng.c': ['ethdev', 'net', 'pcapng', 'bus_vdev', 'net_null'],
     'test_pdcp.c': ['eventdev', 'pdcp', 'net', 'timer', 'security'],
     'test_pdump.c': ['pdump'] + sample_packet_forward_deps,
     'test_per_lcore.c': [],
@@ -209,7 +209,7 @@ source_file_deps = {
     'test_trace.c': [],
     'test_trace_perf.c': [],
     'test_trace_register.c': [],
-    'test_vdev.c': ['kvargs', 'bus_vdev'],
+    'test_vdev.c': ['kvargs', 'bus_vdev', 'net_null'],
     'test_version.c': [],
 }
 
-- 
2.51.0

[PATCH 3/3] drivers: always enable the null net driver [RFC]

[Bruce Richardson]

Having the net_null driver always available can be convenient and allows
use by unit tests, so add this trivial driver to the always-enable list.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>

---
I'm not sure if we want this to be always enabled or not, so sending
this as an RFC. I can see definite advantages to doing so, but I also
dislike having too many components on the always-enable list.

Since I'm ambivilent myself, including this patch so the community can
decide.
---
 drivers/meson.build | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/meson.build b/drivers/meson.build
index 3fe3be48fb..9ed0dba786 100644
--- a/drivers/meson.build
+++ b/drivers/meson.build
@@ -80,6 +80,8 @@ endif
 always_enable = ['bus/pci', 'bus/vdev']
 # we always need a mempool driver, and ring is default, so make it mandatory
 always_enable += ['mempool/ring']
+# unit tests take advantage of net/null driver, so always enable it
+always_enable += ['net/null']
 enable_drivers += always_enable
 
 default_cflags = machine_args
-- 
2.51.0

RE: [PATCH 3/3] drivers: always enable the null net driver [RFC]

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Thursday, 22 January 2026 13.24
> 
> Having the net_null driver always available can be convenient and
> allows
> use by unit tests, so add this trivial driver to the always-enable
> list.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> 
> ---
> I'm not sure if we want this to be always enabled or not, so sending
> this as an RFC. I can see definite advantages to doing so, but I also
> dislike having too many components on the always-enable list.
> 
> Since I'm ambivilent myself, including this patch so the community can
> decide.

I don't think real applications use this.
If they do, they can include it manually.

My main objection is:
We are setting the wrong precedence if we make stuff like this mandatory for convenience.

But I agree with the reason you are suggesting it.

Is there some other way it can be enabled for unit tests?
Maybe the null driver can depend on the unit tests being built?

I don't mind that the driver is being built.
I just don't want it included by default when statically linking a monolithic application.

I'm flexible on this RFC, so it's a very soft NAK from me.
If it can be disabled at build time, I'm OK with it. (But still concerned about setting the wrong precedence.)

> ---
>  drivers/meson.build | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/meson.build b/drivers/meson.build
> index 3fe3be48fb..9ed0dba786 100644
> --- a/drivers/meson.build
> +++ b/drivers/meson.build
> @@ -80,6 +80,8 @@ endif
>  always_enable = ['bus/pci', 'bus/vdev']
>  # we always need a mempool driver, and ring is default, so make it
> mandatory
>  always_enable += ['mempool/ring']
> +# unit tests take advantage of net/null driver, so always enable it
> +always_enable += ['net/null']
>  enable_drivers += always_enable
> 
>  default_cflags = machine_args
> --
> 2.51.0

Re: [PATCH 3/3] drivers: always enable the null net driver [RFC]

[Bruce Richardson]

On Thu, Jan 22, 2026 at 02:13:06PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Thursday, 22 January 2026 13.24
> > 
> > Having the net_null driver always available can be convenient and
> > allows
> > use by unit tests, so add this trivial driver to the always-enable
> > list.
> > 
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > 
> > ---
> > I'm not sure if we want this to be always enabled or not, so sending
> > this as an RFC. I can see definite advantages to doing so, but I also
> > dislike having too many components on the always-enable list.
> > 
> > Since I'm ambivilent myself, including this patch so the community can
> > decide.
> 
> I don't think real applications use this.
> If they do, they can include it manually.
> 
> My main objection is:
> We are setting the wrong precedence if we make stuff like this mandatory for convenience.
> 
> But I agree with the reason you are suggesting it.
> 
> Is there some other way it can be enabled for unit tests?
> Maybe the null driver can depend on the unit tests being built?
> 
> I don't mind that the driver is being built.
> I just don't want it included by default when statically linking a monolithic application.
> 
> I'm flexible on this RFC, so it's a very soft NAK from me.
> If it can be disabled at build time, I'm OK with it. (But still concerned about setting the wrong precedence.)
> 
Yes, I agree.

Why I'm proposing this is because, in order to give me faster rebuilds and
because of the hardware I have available to me, I generally set up my
builds with "-Denable_drivers=net/intel/*", since that really speeds up my
dev-build-test cycle. In doing so, though, I do miss out on having some
unit tests available when I run the fast-test suite, which is why I
suggested this addition in case there are others who limit the builds to
just the hardware they are using.

/Bruce

RE: [PATCH 3/3] drivers: always enable the null net driver [RFC]

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Thursday, 22 January 2026 14.32
> 
> On Thu, Jan 22, 2026 at 02:13:06PM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Thursday, 22 January 2026 13.24
> > >
> > > Having the net_null driver always available can be convenient and
> > > allows
> > > use by unit tests, so add this trivial driver to the always-enable
> > > list.
> > >
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > >
> > > ---
> > > I'm not sure if we want this to be always enabled or not, so
> sending
> > > this as an RFC. I can see definite advantages to doing so, but I
> also
> > > dislike having too many components on the always-enable list.
> > >
> > > Since I'm ambivilent myself, including this patch so the community
> can
> > > decide.
> >
> > I don't think real applications use this.
> > If they do, they can include it manually.
> >
> > My main objection is:
> > We are setting the wrong precedence if we make stuff like this
> mandatory for convenience.
> >
> > But I agree with the reason you are suggesting it.
> >
> > Is there some other way it can be enabled for unit tests?
> > Maybe the null driver can depend on the unit tests being built?
> >
> > I don't mind that the driver is being built.
> > I just don't want it included by default when statically linking a
> monolithic application.
> >
> > I'm flexible on this RFC, so it's a very soft NAK from me.
> > If it can be disabled at build time, I'm OK with it. (But still
> concerned about setting the wrong precedence.)
> >
> Yes, I agree.
> 
> Why I'm proposing this is because, in order to give me faster rebuilds
> and
> because of the hardware I have available to me, I generally set up my
> builds with "-Denable_drivers=net/intel/*", since that really speeds up
> my
> dev-build-test cycle. In doing so, though, I do miss out on having some
> unit tests available when I run the fast-test suite, which is why I
> suggested this addition in case there are others who limit the builds
> to
> just the hardware they are using.

You can build with "-Denable_drivers=net/intel/*,net/null".

Then I'll suggest an alternative to this patch:
Change the fast-test application, so it emits an informational message about which tests are being skipped because the net/null driver is missing.

Re: [PATCH 3/3] drivers: always enable the null net driver [RFC]

[Bruce Richardson]

On Thu, Jan 22, 2026 at 02:40:45PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Thursday, 22 January 2026 14.32
> > 
> > On Thu, Jan 22, 2026 at 02:13:06PM +0100, Morten Brørup wrote:
> > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > Sent: Thursday, 22 January 2026 13.24
> > > >
> > > > Having the net_null driver always available can be convenient and
> > > > allows
> > > > use by unit tests, so add this trivial driver to the always-enable
> > > > list.
> > > >
> > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > >
> > > > ---
> > > > I'm not sure if we want this to be always enabled or not, so
> > sending
> > > > this as an RFC. I can see definite advantages to doing so, but I
> > also
> > > > dislike having too many components on the always-enable list.
> > > >
> > > > Since I'm ambivilent myself, including this patch so the community
> > can
> > > > decide.
> > >
> > > I don't think real applications use this.
> > > If they do, they can include it manually.
> > >
> > > My main objection is:
> > > We are setting the wrong precedence if we make stuff like this
> > mandatory for convenience.
> > >
> > > But I agree with the reason you are suggesting it.
> > >
> > > Is there some other way it can be enabled for unit tests?
> > > Maybe the null driver can depend on the unit tests being built?
> > >
> > > I don't mind that the driver is being built.
> > > I just don't want it included by default when statically linking a
> > monolithic application.
> > >
> > > I'm flexible on this RFC, so it's a very soft NAK from me.
> > > If it can be disabled at build time, I'm OK with it. (But still
> > concerned about setting the wrong precedence.)
> > >
> > Yes, I agree.
> > 
> > Why I'm proposing this is because, in order to give me faster rebuilds
> > and
> > because of the hardware I have available to me, I generally set up my
> > builds with "-Denable_drivers=net/intel/*", since that really speeds up
> > my
> > dev-build-test cycle. In doing so, though, I do miss out on having some
> > unit tests available when I run the fast-test suite, which is why I
> > suggested this addition in case there are others who limit the builds
> > to
> > just the hardware they are using.
> 
> You can build with "-Denable_drivers=net/intel/*,net/null".
> 
> Then I'll suggest an alternative to this patch:
> Change the fast-test application, so it emits an informational message about which tests are being skipped because the net/null driver is missing.
>
That is sadly non-trivial, and if we do so for net-null, we should also do
so for a bunch of other components where we disable tests if they are
missing. But the idea of just informing the user rather than force-enabling
the driver is a good one.

Re: [PATCH 3/3] drivers: always enable the null net driver [RFC]

[Stephen Hemminger]

On Thu, 22 Jan 2026 14:59:21 +0000
Bruce Richardson <bruce.richardson@intel.com> wrote:

>  
> > Then I'll suggest an alternative to this patch:
> > Change the fast-test application, so it emits an informational message about which tests are being skipped because the net/null driver is missing.
> >  
> That is sadly non-trivial, and if we do so for net-null, we should also do
> so for a bunch of other components where we disable tests if they are
> missing. But the idea of just informing the user rather than force-enabling
> the driver is a good one.


I am ok with either of three solutions:
  - require it to be always enabled
  - in meson.build, add dependency on net_null for tests that need it.
    (that is what my patches did)
  - add per test checks for vdev_init failing and return TEST_SKIPPED
    There also is unsupported status, but that doesn't appear to be used
    or work right

Doing dependency at build time is my preference.

Re: [PATCH 3/3] drivers: always enable the null net driver [RFC]

[David Marchand]

On Thu, 22 Jan 2026 at 14:32, Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Thu, Jan 22, 2026 at 02:13:06PM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Thursday, 22 January 2026 13.24
> > >
> > > Having the net_null driver always available can be convenient and
> > > allows
> > > use by unit tests, so add this trivial driver to the always-enable
> > > list.
> > >
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > >
> > > ---
> > > I'm not sure if we want this to be always enabled or not, so sending
> > > this as an RFC. I can see definite advantages to doing so, but I also
> > > dislike having too many components on the always-enable list.
> > >
> > > Since I'm ambivilent myself, including this patch so the community can
> > > decide.
> >
> > I don't think real applications use this.
> > If they do, they can include it manually.
> >
> > My main objection is:
> > We are setting the wrong precedence if we make stuff like this mandatory for convenience.
> >
> > But I agree with the reason you are suggesting it.
> >
> > Is there some other way it can be enabled for unit tests?
> > Maybe the null driver can depend on the unit tests being built?
> >
> > I don't mind that the driver is being built.
> > I just don't want it included by default when statically linking a monolithic application.

Same, I don't want a driver with almost no maintenance on it (even if
it is trivial code) to be linked in a final application.
(it would be a pity to get a CVE because of net/null ;-))


> >
> > I'm flexible on this RFC, so it's a very soft NAK from me.
> > If it can be disabled at build time, I'm OK with it. (But still concerned about setting the wrong precedence.)
> >
> Yes, I agree.
>
> Why I'm proposing this is because, in order to give me faster rebuilds and
> because of the hardware I have available to me, I generally set up my
> builds with "-Denable_drivers=net/intel/*", since that really speeds up my
> dev-build-test cycle. In doing so, though, I do miss out on having some
> unit tests available when I run the fast-test suite, which is why I
> suggested this addition in case there are others who limit the builds to
> just the hardware they are using.

Unit tests are mainly run by the CI or DPDK developers, so how about
putting this addition in the always enabled list under the
developer_mode check?


-- 
David Marchand

Re: [PATCH 3/3] drivers: always enable the null net driver [RFC]

[Bruce Richardson]

On Thu, Jan 22, 2026 at 02:47:47PM +0100, David Marchand wrote:
> On Thu, 22 Jan 2026 at 14:32, Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > On Thu, Jan 22, 2026 at 02:13:06PM +0100, Morten Brørup wrote:
> > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > Sent: Thursday, 22 January 2026 13.24
> > > >
> > > > Having the net_null driver always available can be convenient and
> > > > allows
> > > > use by unit tests, so add this trivial driver to the always-enable
> > > > list.
> > > >
> > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > >
> > > > ---
> > > > I'm not sure if we want this to be always enabled or not, so sending
> > > > this as an RFC. I can see definite advantages to doing so, but I also
> > > > dislike having too many components on the always-enable list.
> > > >
> > > > Since I'm ambivilent myself, including this patch so the community can
> > > > decide.
> > >
> > > I don't think real applications use this.
> > > If they do, they can include it manually.
> > >
> > > My main objection is:
> > > We are setting the wrong precedence if we make stuff like this mandatory for convenience.
> > >
> > > But I agree with the reason you are suggesting it.
> > >
> > > Is there some other way it can be enabled for unit tests?
> > > Maybe the null driver can depend on the unit tests being built?
> > >
> > > I don't mind that the driver is being built.
> > > I just don't want it included by default when statically linking a monolithic application.
> 
> Same, I don't want a driver with almost no maintenance on it (even if
> it is trivial code) to be linked in a final application.
> (it would be a pity to get a CVE because of net/null ;-))
> 
> 
> > >
> > > I'm flexible on this RFC, so it's a very soft NAK from me.
> > > If it can be disabled at build time, I'm OK with it. (But still concerned about setting the wrong precedence.)
> > >
> > Yes, I agree.
> >
> > Why I'm proposing this is because, in order to give me faster rebuilds and
> > because of the hardware I have available to me, I generally set up my
> > builds with "-Denable_drivers=net/intel/*", since that really speeds up my
> > dev-build-test cycle. In doing so, though, I do miss out on having some
> > unit tests available when I run the fast-test suite, which is why I
> > suggested this addition in case there are others who limit the builds to
> > just the hardware they are using.
> 
> Unit tests are mainly run by the CI or DPDK developers, so how about
> putting this addition in the always enabled list under the
> developer_mode check?
> 

Yep could work. Possibly also taking a modified version of Morten's
suggestion about warning about skipped tests, what about just emitting a
warning from meson if we are in developer mode and we haven't the net-null
driver enabled?

/Bruce

RE: [PATCH 3/3] drivers: always enable the null net driver [RFC]

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Thursday, 22 January 2026 15.57
> 
> On Thu, Jan 22, 2026 at 02:47:47PM +0100, David Marchand wrote:
> > On Thu, 22 Jan 2026 at 14:32, Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > On Thu, Jan 22, 2026 at 02:13:06PM +0100, Morten Brørup wrote:
> > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > > Sent: Thursday, 22 January 2026 13.24
> > > > >
> > > > > Having the net_null driver always available can be convenient
> and
> > > > > allows
> > > > > use by unit tests, so add this trivial driver to the always-
> enable
> > > > > list.
> > > > >
> > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > >
> > > > > ---
> > > > > I'm not sure if we want this to be always enabled or not, so
> sending
> > > > > this as an RFC. I can see definite advantages to doing so, but
> I also
> > > > > dislike having too many components on the always-enable list.
> > > > >
> > > > > Since I'm ambivilent myself, including this patch so the
> community can
> > > > > decide.
> > > >
> > > > I don't think real applications use this.
> > > > If they do, they can include it manually.
> > > >
> > > > My main objection is:
> > > > We are setting the wrong precedence if we make stuff like this
> mandatory for convenience.
> > > >
> > > > But I agree with the reason you are suggesting it.
> > > >
> > > > Is there some other way it can be enabled for unit tests?
> > > > Maybe the null driver can depend on the unit tests being built?
> > > >
> > > > I don't mind that the driver is being built.
> > > > I just don't want it included by default when statically linking
> a monolithic application.
> >
> > Same, I don't want a driver with almost no maintenance on it (even if
> > it is trivial code) to be linked in a final application.
> > (it would be a pity to get a CVE because of net/null ;-))
> >
> >
> > > >
> > > > I'm flexible on this RFC, so it's a very soft NAK from me.
> > > > If it can be disabled at build time, I'm OK with it. (But still
> concerned about setting the wrong precedence.)
> > > >
> > > Yes, I agree.
> > >
> > > Why I'm proposing this is because, in order to give me faster
> rebuilds and
> > > because of the hardware I have available to me, I generally set up
> my
> > > builds with "-Denable_drivers=net/intel/*", since that really
> speeds up my
> > > dev-build-test cycle. In doing so, though, I do miss out on having
> some
> > > unit tests available when I run the fast-test suite, which is why I
> > > suggested this addition in case there are others who limit the
> builds to
> > > just the hardware they are using.
> >
> > Unit tests are mainly run by the CI or DPDK developers, so how about
> > putting this addition in the always enabled list under the
> > developer_mode check?
> >

I like this idea, but there's a similar risk of adding unnecessary stuff; now it's only limited to developer_mode.

E.g. what else should be added in developer_mode to extend testing beyond what the developer explicitly configures?

And what if the developer doesn't want these added tests (considering them a waste of time and resources)?

> 
> Yep could work. Possibly also taking a modified version of Morten's
> suggestion about warning about skipped tests, what about just emitting
> a
> warning from meson if we are in developer mode and we haven't the net-
> null
> driver enabled?

I like this idea.
But it requires some sort of coordination/synchronization between development of the test applications and the meson build script.
I.e. when developing a new test case, dependencies need to be considered and possibly worked into the meson build script.
This coordination will probably be forgotten.
But even if forgotten, it will be remembered again next time a real need occurs.

[PATCH v2 0/4] improve net/null dependency handling for tests

[Bruce Richardson]

A number of unit tests take advantage of net_null driver to use
as a dummy packet source. When this driver is disabled we then get
tests failures in fast-tests. Fix these by recording the dependency
appropriately or by skipping test sections if the dependency isn't
present.

V2: reworked changes following feedback, discussion and other upstream
    changes

Bruce Richardson (4):
  test/event_eth_rx_adapter: skip tests if no ethdevs
  test/event_eth_tx_adapter: remove dependency on NULL PMD
  test: fix missing dependency on null networking driver
  build/tests: add warning for missing NULL PMD dependency

 app/test/meson.build                 | 10 ++++++++--
 app/test/test_event_eth_rx_adapter.c | 14 ++++++++++----
 app/test/test_event_eth_tx_adapter.c |  4 ++++
 3 files changed, 22 insertions(+), 6 deletions(-)

--
2.51.0

[PATCH v2 1/4] test/event_eth_rx_adapter: skip tests if no ethdevs

[Bruce Richardson]

If no ethdevs are present and devices cannot be created via net_null
driver, skip the tests rather than failing them.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 app/test/test_event_eth_rx_adapter.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/app/test/test_event_eth_rx_adapter.c b/app/test/test_event_eth_rx_adapter.c
index 2b623bfb28..ae428b3333 100644
--- a/app/test/test_event_eth_rx_adapter.c
+++ b/app/test/test_event_eth_rx_adapter.c
@@ -251,8 +251,11 @@ testsuite_setup(void)
 	if (!count) {
 		printf("Testing with net_null device\n");
 		err = rte_vdev_init("net_null", NULL);
-		TEST_ASSERT(err == 0, "Failed to create net_null. err=%d",
-			    err);
+		if (err != 0) {
+			printf("Failed to create net_null, skipping tests. err=%d\n",
+				err);
+			return TEST_SKIPPED;
+		}
 		eth_dev_created = true;
 	}
 
@@ -311,8 +314,11 @@ testsuite_setup_rx_intr(void)
 	if (!count) {
 		printf("Testing with net_null device\n");
 		err = rte_vdev_init("net_null", NULL);
-		TEST_ASSERT(err == 0, "Failed to create net_null. err=%d",
-			    err);
+		if (err != 0) {
+			printf("Failed to create net_null, skipping tests. err=%d\n",
+				err);
+			return TEST_SKIPPED;
+		}
 		eth_dev_created = true;
 	}
 
-- 
2.51.0

[PATCH v2 2/4] test/event_eth_tx_adapter: remove dependency on NULL PMD

[Bruce Richardson]

The eventdev eth Tx adapter only uses the net_null driver for the final
test case within the suite. Rather than adding an explicit dependency on
that driver, just report the last case as skipped if not present.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 app/test/test_event_eth_tx_adapter.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/app/test/test_event_eth_tx_adapter.c b/app/test/test_event_eth_tx_adapter.c
index a128a4f2c2..bec298a8b8 100644
--- a/app/test/test_event_eth_tx_adapter.c
+++ b/app/test/test_event_eth_tx_adapter.c
@@ -937,6 +937,7 @@ tx_adapter_set_get_params(void)
 static int
 tx_adapter_dynamic_device(void)
 {
+#ifdef RTE_NET_NULL
 	uint16_t port_id = rte_eth_dev_count_avail();
 	const char *null_dev[2] = { "eth_null0", "eth_null1" };
 	struct rte_eth_conf dev_conf;
@@ -977,6 +978,9 @@ tx_adapter_dynamic_device(void)
 		rte_vdev_uninit(null_dev[i]);
 
 	return TEST_SUCCESS;
+#else
+	return TEST_SKIPPED;
+#endif
 }
 
 static struct unit_test_suite event_eth_tx_tests = {
-- 
2.51.0

[PATCH v2 3/4] test: fix missing dependency on null networking driver

[Bruce Richardson]

A number of tests depend upon the null networking driver in order to
run, so record that dependency in the meson file, so they are skipped if
it's not present.

Fixes: 50823f30f0c8 ("test: build using per-file dependencies")
Cc: stable@dpdk.org

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 app/test/meson.build | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app/test/meson.build b/app/test/meson.build
index 4fd8670e05..31c966d97e 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -112,7 +112,7 @@ source_file_deps = {
         'net'] + packet_burst_generator_deps + virtual_pmd_deps,
     'test_link_bonding_mode4.c': ['ethdev', 'net_ring', 'net_bond',
         'net'] + packet_burst_generator_deps,
-    'test_link_bonding_rssconf.c': ['ethdev', 'bus_vdev', 'net_bond'],
+    'test_link_bonding_rssconf.c': ['ethdev', 'bus_vdev', 'net_bond', 'net_null'],
     'test_logs.c': [],
     'test_lpm.c': ['net', 'lpm'],
     'test_lpm6.c': ['lpm'],
@@ -209,7 +209,7 @@ source_file_deps = {
     'test_trace.c': [],
     'test_trace_perf.c': [],
     'test_trace_register.c': [],
-    'test_vdev.c': ['kvargs', 'bus_vdev'],
+    'test_vdev.c': ['kvargs', 'bus_vdev', 'net_null'],
     'test_version.c': [],
 }
 
-- 
2.51.0

[PATCH v2 4/4] build/tests: add warning for missing NULL PMD dependency

[Bruce Richardson]

In developer builds, warn the user if they are building the unit tests
but don't have net_null enabled, since a number of suites and test cases
within suites depend on that to create dummy ethdev devices for testing.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 app/test/meson.build | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/app/test/meson.build b/app/test/meson.build
index 31c966d97e..5dde50b181 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -218,6 +218,12 @@ source_file_ext_deps = {
     'test_pcapng.c': ['pcap'],
 }
 
+# the NULL ethdev is used by a number of tests, in some cases as an optional dependency.
+# for developer builds, warn user if its missing and we are building the tests.
+if not dpdk_conf.has('RTE_NET_NULL') and developer_mode
+    warning('For unit testing, the net/null PMD should be enabled in the build to enable tests that depend on it.')
+endif
+
 def_lib = get_option('default_library')
 foreach f, f_deps : source_file_deps
     has_deps = true
-- 
2.51.0

RE: [PATCH v2 0/4] improve net/null dependency handling for tests

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Thursday, 19 February 2026 18.40
> 
> A number of unit tests take advantage of net_null driver to use
> as a dummy packet source. When this driver is disabled we then get
> tests failures in fast-tests. Fix these by recording the dependency
> appropriately or by skipping test sections if the dependency isn't
> present.
> 
> V2: reworked changes following feedback, discussion and other upstream
>     changes

A solution very much to my taste!

Series-acked-by: Morten Brørup <mb@smartsharesystems.com>

Re: [PATCH v2 0/4] improve net/null dependency handling for tests

[David Marchand]

On Thu, 19 Feb 2026 at 18:40, Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> A number of unit tests take advantage of net_null driver to use
> as a dummy packet source. When this driver is disabled we then get
> tests failures in fast-tests. Fix these by recording the dependency
> appropriately or by skipping test sections if the dependency isn't
> present.
>
> V2: reworked changes following feedback, discussion and other upstream
>     changes
>
> Bruce Richardson (4):
>   test/event_eth_rx_adapter: skip tests if no ethdevs
>   test/event_eth_tx_adapter: remove dependency on NULL PMD
>   test: fix missing dependency on null networking driver
>   build/tests: add warning for missing NULL PMD dependency
>
>  app/test/meson.build                 | 10 ++++++++--
>  app/test/test_event_eth_rx_adapter.c | 14 ++++++++++----
>  app/test/test_event_eth_tx_adapter.c |  4 ++++
>  3 files changed, 22 insertions(+), 6 deletions(-)

Series applied, thanks.


-- 
David Marchand