On Tue, 22 Sep 2026 11:40:16 +0200 David Marchand <[email protected]> wrote:
> We had a few bug reports related to internal (and experimental) symbols > issues during 26.07 development. > See for example https://bugs.dpdk.org/show_bug.cgi?id=1957 or more > recently https://bugs.dpdk.org/show_bug.cgi?id=1967. > > To catch such issues earlier in the CI, this series proposes to run > the unit tests through meson with the ABI reference unit test binary > against the current ABI libraries and drivers. > > For this to work, some unit tests must be skipped (since meson may > invoke the ABI reference code with tests that were unknown at the time). > > A few unit tests were directly dereferencing internal structures and are > reworked so they use public APIs. > > Additionally, unit tests were allowed to use any internal API which has > hidden a few issues (like a public API backed by internal symbols in the > hash library). > So disable the global ALLLOW_INTERNAL_API and move it to code explicitly > requiring internal API, with the hope it will push us to have better API. I think this causing breakage with minsize build. It is not correct to use __rte_internal on inline helper functions in header file. I checked and only thash has that anti-pattern. In file included from ../lib/hash/rte_thash_gfni.h:13, from ../lib/hash/rte_thash.h:23, from ../app/test/test_thash_perf.c:13: In function ‘rte_thash_gfni’, inlined from ‘run_rss_calc’ at ../app/test/test_thash_perf.c:58:13: ../lib/hash/rte_thash_x86_gfni.h:181:27: error: call to ‘__rte_thash_gfni’ declared with attribute error: Symbol is not public ABI 181 | __m512i xor_acc = __rte_thash_gfni(m, tuple, NULL, len); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function ‘rte_thash_gfni_bulk’, inlined from ‘run_rss_calc_bulk’ at ../app/test/test_thash_perf.c:79:3, inlined from ‘run_thash_test’ at ../app/test/test_thash_perf.c:122:13: ../lib/hash/rte_thash_x86_gfni.h:213:27: error: call to ‘__rte_thash_gfni’ declared with attribute error: Symbol is not public ABI 213 | xor_acc = __rte_thash_gfni(mtrx, tuple[i], tuple[i + 1], len); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ AI analysis: Pre-existing: the actual bug lib/hash/rte_thash_x86_gfni.h:32 and :67 put __rte_internal on two static inline helpers, __rte_thash_xor_reduce and __rte_thash_gfni. The public, stable (per b9dd86db2a) wrappers rte_thash_gfni() / rte_thash_gfni_bulk() call them. Those markers date to 4fd8c4cb0d ("hash: add new Toeplitz hash implementation") — they've always been wrong. Any external application including rte_thash.h without ALLOW_INTERNAL_API was already broken; 1f1c91397c just made DPDK's own tree hit the same wall. This is the same class of bug da31ef54c8 ("hash: fix GFNI stubs export") fixed for the out-of-line stubs — it missed the inline helpers. Why only minsize __rte_internal expands to __attribute__((error(...))), which only fires if the call survives to codegen: -O0 : 6 -O1 : 0 -O2 : 0 -O3 : 0 -Os : 2 At -O1/-O2/-O3 GCC inlines the helper and the call vanishes. At -Os it declines to inline (function too large), at -O0 it never inlines. So the marker was never actually enforcing anything at the default optimization levels — it only detonates under specific inlining decisions. minsize and a debug build are the two configs that expose it. Recommended fix Drop __rte_internal from those two static inline helpers, rather than restoring ALLOW_INTERNAL_API to app/test. __rte_internal on a static inline in an installed public header is wrong by construction: there's no exported symbol to protect, and it makes the public wrappers unusable from outside DPDK. Verified: with those two markers removed, test_thash.c and test_thash_perf.c both compile clean at -O0 and -Os (6→0 and 2→0). I grepped the rest of lib/ and drivers/ for __rte_internal immediately preceding static inline in public headers — these two are the only instances, so a single small patch covers it. Fixes: should point at 4fd8c4cb0d, not 1f1c91397c.
