I support this change but I agree with Dave, let's target maybe next Tue call to have a proper discussion? And if anyone else have opinions, please share it :)
Best ben ________________________________________ From: [email protected] <[email protected]> on behalf of Dave Wallace via lists.fd.io <[email protected]> Sent: Wednesday, September 2, 2026 0:36 To: [email protected] Cc: Jerome Tollet (jtollet) Subject: Re: [vpp-dev] libvnet ABI breaking change (was: Performance impact of internal libvnet PLT calls) Hi Jerome, Thank you for the RFP! I have added Code-Review -2 to the gerrit 46573 mentioned below not because I am opposed to the improvement that it will provide, but for the following reasons: 1. it is an ABI breaking change of all of the core VPP networking features 2. overall size and scope of the changes has an unknown and potentially huge blast radius 3. insufficient community feedback on the RFP (most likely due to summer vacation season & the innocuous title of this thread) 4. the breaking change is the default (IMHO, an opt-in behavior would be acceptable) 5. the export check does not currently support out-of-tree plugins My recommendation is these issues be discussed further here and in either a special VPP Community Technical session the week of Sept or in the first October VPP Community meeting. Unfortunately I'm not available for the two scheduled VPP community meetings in September. All comments welcome. Thanks, -daw- On 8/26/26 3:02 AM, Jerome Tollet via lists.fd.io wrote: Hi all, I have posted an RFC/WIP series implementing hidden visibility for libvnet: - https://gerrit.fd.io/r/c/vpp/+/46571 build: add target-scoped hidden visibility support for libraries - https://gerrit.fd.io/r/c/vpp/+/46572 vlib: remove the packet trace filter weak-symbol interposition - https://gerrit.fd.io/r/c/vpp/+/46573 vnet: enable hidden visibility, add explicit function and data exports, and check the exports required by in-tree consumers The export check passes with Clang and GCC on x86 and with Clang on a BlueField-3. An x86 runtime check also loaded all 104 configured plugins without symbol resolution errors. The current arm64 hidden build has 1,017 dynamic definitions and 939 JUMP_SLOT relocations. I have not yet run a performance A/B/A on this exact hidden-visibility implementation, so I am not deriving a speedup from those relocation counts. The initial export set covers all in-tree consumers, including data symbols. Out-of-tree plugins may identify additional required exports; I would treat those in the same way as other VPP API changes and add the justified symbols as they are found. Does this look like a direction people are comfortable with? Unless anyone objects, I will continue refining the series based on review and run the direct ARM A/B/A on the hidden implementation. Best, Jerome
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#27161): https://lists.fd.io/g/vpp-dev/message/27161 Mute This Topic: https://lists.fd.io/mt/121042664/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
