Hi all,
Thanks Ben. I have now repeated the -Bsymbolic-functions diagnostic on an 
NVIDIA BlueField-3 (Arm Cortex-A78AE).

I used a real application workload over the VPP HostStack and a physical 100 
GbE link, with four VPP workers. This is not a packet-forwarding benchmark, so 
the results are expressed in application requests rather than packets. The 
comparison used the exact same object files; only libvnet was relinked with 
-Wl,-Bsymbolic-functions. An A/B/A test across six workload profiles showed:
- geometric-mean request rate: +4.32%
- latency-sensitive profiles: +8% to +11% per core

The number of JUMP_SLOT relocations in libvnet decreased from 2,167 to 382.

A separate PMU-assisted latency-sensitive run showed +15.35% request rate, with 
13.3% fewer cycles per request and 17.6% fewer instructions per request. Unlike 
Skylake-SP, the raw branch-miss count did not decrease significantly. The 
microarchitectural signature is therefore different, but the PLT path still has 
a measurable performance cost on BlueField-3.

This supports investigating Ben’s proposal to compile libvnet with hidden 
visibility and explicit symbol exports. I have not tested that implementation 
yet; -Bsymbolic-functions remains only a diagnostic here.

The next step would be to identify the intended public libvnet API, explicitly 
export those symbols, and check whether any supported use case relies on 
interposition.
Jerome

De : [email protected] <[email protected]> de la part de Benoit Ganne 
(bganne) via lists.fd.io <[email protected]>
Date : jeudi, 23 juillet 2026 à 16:14
À : vpp-dev <[email protected]>
Objet : Re: [vpp-dev] Performance impact of internal libvnet PLT calls

Hi,

> I observed a significant performance impact from internal libvnet calls going 
> through the PLT on a Xeon Platinum 8168 (Skylake-SP).
> As a diagnostic test, I linked libvnet with -Wl,-Bsymbolic-functions.

Given that other part of VPP (eg. vppinfra and plugins) are compiled with 
-fvisibility=hidden with explicit symbol exports, I think we should do the same 
for libvnet. That should give us the same benefits and would be consistent with 
the rest of VPP.
Thoughts?

Best,
ben
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#27118): https://lists.fd.io/g/vpp-dev/message/27118
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]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to