Disable SPDK testing again?

Disable SPDK testing again?

[David Marchand]

Hello,

The SPDK target in UNH lab has been spewing warnings as SPDK build
itself compiles and links against a list of libraries and drivers,
regardless of the upstream dependencies.
https://github.com/spdk/dpdk/commit/74b1a804eda2ed99d1ecaae5b79de7df6d74e8ff and
https://github.com/spdk/spdk/blob/master/dpdkbuild/Makefile#L66


Until SPDK fixes this on their side (either adding argparse in their
static list, or using pkg-config for example and stopping patching
DPDK), linking SPDK binaries fails as the argparse lib now necessary
to EAL is not pulled:

/usr/bin/ld.bfd:
/usr/local/lib/x86_64-linux-gnu/librte_eal.a(eal_common_eal_common_options.c.o):
in function `eal_usage':
eal_common_options.c:(.text+0x16): undefined reference to
`rte_argparse_print_help'
/usr/bin/ld.bfd:
/usr/local/lib/x86_64-linux-gnu/librte_eal.a(eal_common_eal_common_options.c.o):
in function `eal_collate_args':
eal_common_options.c:(.text+0x953): undefined reference to `rte_argparse_parse'
/usr/bin/ld.bfd:
/usr/local/lib/x86_64-linux-gnu/librte_eal.a(eal_common_eal_common_options.c.o):
in function `eal_parse_args':
eal_common_options.c:(.text+0x343b): undefined reference to
`rte_argparse_parse_type'
collect2: error: ld returned 1 exit status
make[3]: *** [/root/workspace/Generic-DPDK-Compile-Meson/spdk/mk/spdk.app.mk:39:
spdk_lock] Error 1
make[2]: *** [/root/workspace/Generic-DPDK-Compile-Meson/spdk/mk/spdk.subdirs.mk:16:
lock] Error 2
make[1]: *** [/root/workspace/Generic-DPDK-Compile-Meson/spdk/mk/spdk.subdirs.mk:16:
thread] Error 2


While it is just a warning in the CI dashboard, I don't think we
should waste resources on this testing.
Opinions?


-- 
David Marchand

RE: Disable SPDK testing again?

[Morten Brørup]

> From: David Marchand [mailto:david.marchand@redhat.com]
> Sent: Friday, 31 October 2025 09.39
> 
> Hello,
> 
> The SPDK target in UNH lab has been spewing warnings as SPDK build
> itself compiles and links against a list of libraries and drivers,
> regardless of the upstream dependencies.
> https://github.com/spdk/dpdk/commit/74b1a804eda2ed99d1ecaae5b79de7df6d7
> 4e8ff and
> https://github.com/spdk/spdk/blob/master/dpdkbuild/Makefile#L66
> 
> 
> Until SPDK fixes this on their side (either adding argparse in their
> static list, or using pkg-config for example and stopping patching
> DPDK), linking SPDK binaries fails as the argparse lib now necessary
> to EAL is not pulled:
> 
> /usr/bin/ld.bfd:
> /usr/local/lib/x86_64-linux-
> gnu/librte_eal.a(eal_common_eal_common_options.c.o):
> in function `eal_usage':
> eal_common_options.c:(.text+0x16): undefined reference to
> `rte_argparse_print_help'
> /usr/bin/ld.bfd:
> /usr/local/lib/x86_64-linux-
> gnu/librte_eal.a(eal_common_eal_common_options.c.o):
> in function `eal_collate_args':
> eal_common_options.c:(.text+0x953): undefined reference to
> `rte_argparse_parse'
> /usr/bin/ld.bfd:
> /usr/local/lib/x86_64-linux-
> gnu/librte_eal.a(eal_common_eal_common_options.c.o):
> in function `eal_parse_args':
> eal_common_options.c:(.text+0x343b): undefined reference to
> `rte_argparse_parse_type'
> collect2: error: ld returned 1 exit status
> make[3]: *** [/root/workspace/Generic-DPDK-Compile-
> Meson/spdk/mk/spdk.app.mk:39:
> spdk_lock] Error 1
> make[2]: *** [/root/workspace/Generic-DPDK-Compile-
> Meson/spdk/mk/spdk.subdirs.mk:16:
> lock] Error 2
> make[1]: *** [/root/workspace/Generic-DPDK-Compile-
> Meson/spdk/mk/spdk.subdirs.mk:16:
> thread] Error 2
> 
> 
> While it is just a warning in the CI dashboard, I don't think we
> should waste resources on this testing.
> Opinions?

We should ask ourselves why they are doing that.
Is something wrong (or incomplete) with our handling of -Denable_libs?
Are we including unnecessary optional libs?

It seems like they are using -Ddisable_libs, not -Denable_libs. Don't they know about -Denable_libs?

Re: Disable SPDK testing again?

[David Marchand]

On Fri, 31 Oct 2025 at 10:11, Morten Brørup <mb@smartsharesystems.com> wrote:
 > While it is just a warning in the CI dashboard, I don't think we
> > should waste resources on this testing.
> > Opinions?
>
> We should ask ourselves why they are doing that.
> Is something wrong (or incomplete) with our handling of -Denable_libs?
> Are we including unnecessary optional libs?
>
> It seems like they are using -Ddisable_libs, not -Denable_libs. Don't they know about -Denable_libs?

I reached out to some SPDK dev when I was working on enable_libs.
I also Cc: one of them on the patches but never got a reply.


-- 
David Marchand

RE: Disable SPDK testing again?

[Morten Brørup]

> From: David Marchand [mailto:david.marchand@redhat.com]
> Sent: Friday, 31 October 2025 10.18
> 
> On Fri, 31 Oct 2025 at 10:11, Morten Brørup <mb@smartsharesystems.com>
> wrote:
>  > While it is just a warning in the CI dashboard, I don't think we
> > > should waste resources on this testing.
> > > Opinions?
> >
> > We should ask ourselves why they are doing that.
> > Is something wrong (or incomplete) with our handling of -
> Denable_libs?
> > Are we including unnecessary optional libs?
> >
> > It seems like they are using -Ddisable_libs, not -Denable_libs. Don't
> they know about -Denable_libs?
> 
> I reached out to some SPDK dev when I was working on enable_libs.
> I also Cc: one of them on the patches but never got a reply.

@Bruce, the SPDK patch [1] was signed off by Tomasz Zawadzki <tomasz.zawadzki@intel.com>; maybe you could try reaching out through internal Intel channels and educate him about -Denable_libs.

If we disable SPDK testing due to this SPDK bug, how will we notice when they fix it, so we can enable SPDK testing again?

[1]: https://github.com/spdk/dpdk/commit/74b1a804eda2ed99d1ecaae5b79de7df6d74e8ff

Re: Disable SPDK testing again?

[Patrick Robb]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

On Fri, Oct 31, 2025 at 6:02 AM Morten Brørup <mb@smartsharesystems.com>
wrote:

>
> If we disable SPDK testing due to this SPDK bug, how will we notice when
> they fix it, so we can enable SPDK testing again?
>
>
One option is I can disable SPDK testing for the "per-patch" testing, but
leave it enabled for the periodic (once per 48 hours) runs on DPDK main.
That way patch submitters aren't left wondering if their patch has broken
SPDK, but we will be able to check in later on the DPDK main periodic
builds to see if the SPDK side is fixed, at which point we can re-enable
SPDK for per-patch testing.

[-- Attachment #2: Type: text/html, Size: 983 bytes --]

RE: Disable SPDK testing again?

[Morten Brørup]

> From: Patrick Robb [mailto:probb@iol.unh.edu] 
> Sent: Friday, 31 October 2025 16.13
> 
> On Fri, Oct 31, 2025 at 6:02 AM Morten Brørup <mb@smartsharesystems.com> wrote:
> 
>> If we disable SPDK testing due to this SPDK bug, how will we notice when they fix it, so we can enable SPDK testing again?
>
>> One option is I can disable SPDK testing for the "per-patch" testing, but leave it enabled for the periodic (once per 48 hours) runs on DPDK main. That way patch submitters aren't left wondering if their patch has broken SPDK, but we will be able to check in later on the DPDK main periodic builds to see if the SPDK side is fixed, at which point we can re-enable SPDK for per-patch testing.

Yes, please do.