Re: [PATCH v4 0/9] Limit usage of internal API in tests

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue, 22 Sep 2026 11:40:16 +0200
David Marchand <david.marchand@redhat.com> 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.