Hi Jerome, My quick 2c
External, not in-tree, plugins reach directly into fib/ip/session, often through header inlines that dereference core globals (ip4_main, session_main, other pools), so the export set has to cover data symbols, not just functions, and we can't prove that set complete from in-tree plugins alone. A missing data symbol is a silent dlopen failure downstream. We can incrementally work on this if we want tighter control, but just switching to hidden visibility will have a lot of side effects. -Bsymbolic-functions doesn't have that failure mode, i.e., nothing leaves .dynsym, so every external plugin that calls into vnet keeps resolving, it only defeats interposition. And since we extend almost entirely through vfts/registration rather than symbol override, the only interposition points that binding would break are our weak symbols. So we should probably audit those if we want to improve Skylakes. Regards, Florin > On Aug 24, 2026, at 10:05 AM, Jerome Tollet via lists.fd.io > <[email protected]> wrote: > > Hi all, > > Following up after rechecking the raw data and the x86 cross-checks. > > The linker-only A/B results are: > > - Xeon Platinum 8168 (Skylake-SP): +17.7% application throughput, > -14.9% cycles/packet, and branch misses down from 8.17 to 3.37/packet. > - Xeon Gold 6248R (Cascade Lake): +0.93% throughput and -0.92% > cycles/packet; the branch-miss rate stayed at about 0.068%. > - BlueField-3 (Cortex-A78AE): strict A/B/A over six application profiles, > +4.32% geometric-mean request rate and +8.4% to +11.4% requests/core > for the two QD1 profiles. JUMP_SLOT relocations fell from 2,167 to 382. > > On a Xeon Platinum 8562Y+ (Sapphire Rapids), an existing PMU run of the > ordinary PLT build measured only 0.226 branch miss/packet (0.086%) while the > 100 GbE workload was already at about 93.3 Gbit/s. This was not a > -Bsymbolic-functions A/B, so I am not deriving a speedup from it; it is only > evidence that the large Skylake effect is microarchitecture-dependent. > > On current master, libvnet is not compiled with hidden visibility, and the > only explicit __clib_export family under src/vnet is the crypto-engine > registration. Ben's proposal is therefore mainly a public-API inventory task, > not just a CMake change. Also, hidden visibility is not exactly equivalent to > the diagnostic: non-exported definitions become direct, but explicitly > exported symbols remain preemptible and internal calls to them may still use > the PLT. > > I suggest an RFC that: > > 1. builds libvnet with hidden visibility and annotates the intended API; > 2. starts the export list from undefined references in shipped VPP binaries > and plugins, then reviews additions needed by supported external plugins; > 3. adds a CI check for the dynamic-symbol list and loads all in-tree plugins; > 4. repeats the A/B on the actual hidden/export implementation. > > If no supported use case relies on interposition, we can then decide whether > exported functions also need non-preemptible internal binding. > > Would this be a reasonable starting point for an RFC? > > Best, > Jerome > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#27143): https://lists.fd.io/g/vpp-dev/message/27143 Mute This Topic: https://lists.fd.io/mt/120410674/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
