Hi Jerome,
I understand your assertion about ABI stability and would like input
from more than 2 people from the community to come up with a consensus
as to whether changes to the ABI of this magnitude should require
advanced notice. Please hold a discussion at tomorrow's VPP Community
meeting and report back on this thread with the specifics of who
attended the meeting and opinions expressed on this topic. Also, please
ask folks at the meeting to respond to this email thread with their opinion.
IMHO, the best way to move this RFP to acceptance is as follows:
1. Add the standalone out-of-tree ABI checker and document it.
2. Provide a means in cmake to select hidden visibility for libvnet, but
leave the current visibility as the default
3. Merge RFP gerrit changes
4. Continue discussion on how to handle large ABI breaking changes here
and at VPP Community meetings, then document it
5. Post VPP 26.10 RC1 / branch pull (9/23/2026), push/merge a new gerrit
change which flips the default to hidden visibility for libvnet
6. Add a release note to VPP 26.10, documenting in which release hidden
visibility for libvnet will become default and provide links to the
out-of-tree ABI checker documentation, the RFP gerrit changes, and how
to opt-out of the ABI change using the mechanism in step 2
Thanks,
-daw-
On 9/2/26 3:41 AM, Jerome Tollet via lists.fd.io wrote:
Hi Dave, all,
Thank you for listing the concerns clearly. I understand the concern about
downstream compatibility, and I agree that the blast radius should be
measurable and that out-of-tree plugin maintainers need a practical migration
path. However, I believe these concerns can be addressed concretely without
delaying the discussion until October.
On ABI compatibility, there is no documented policy guaranteeing a stable
libvnet ABI. Across the five release transitions from VPP 24.10 to 26.06, among
functions both exported by libvnet and declared in installed headers, 262
functions were added, 92 were removed, and 64 material prototype changes
affected 62 distinct functions. These included 22 argument-count changes, 35
argument-type changes, and 7 return-type changes. I have attached the detailed
results and methodology.
This does not make downstream compatibility irrelevant. It does mean, however,
that requiring ABI stability specifically for this change would be inconsistent
unless the same requirement were documented and applied to every libvnet change
that removes an exported symbol or modifies an exported prototype.
More importantly, this change improves our control over the libvnet interface.
Today, any non-static symbol may become part of the dynamic interface
accidentally. Hidden visibility with explicit exports turns that accidental
interface into an intentional, reviewable, and CI-checked export set. It
therefore provides a much stronger foundation for defining and maintaining a
stable ABI in the future, should the project decide to make that commitment.
This is also not merely a visibility cleanup. The optimization that motivated
this work produced measurable performance improvements, particularly on ARM.
Measurements showed clear gains across several workloads, with the largest
improvements in latency-sensitive profiles. The purpose of the proposed series
is to obtain those benefits through explicit visibility control while
preserving the symbols that consumers actually require.
Regarding the blast radius, the current patch already checks all in-tree
consumers, and the runtime validation successfully loaded all 104 configured
plugins. The checks have also passed with GCC and Clang on x86, and with Clang
on ARM64.
Florin's concern about global data is already addressed by the current patch:
the export inventory and CI check cover OBJECT and TLS symbols as well as
functions, and the data symbols required by in-tree consumers are explicitly
exported.
The remaining limitation is completeness for out-of-tree consumers, since their
requirements cannot be inferred from the VPP source tree alone. To address
that, I propose exposing the existing ELF-based checker as a standalone command
accepting one or more external plugin binaries. It would report any required
libvnet function, object, or TLS symbol missing from the explicit export set,
without requiring the plugin sources or integration into the VPP build.
Regarding the default, making hidden visibility permanently opt-in would
provide little practical benefit, and the non-default configuration would
probably receive insufficient CI coverage. To simplify review, I can clearly
separate the visibility mechanism, the export checks, the out-of-tree checker,
and the activation of hidden visibility. If a transitional opt-in period is
considered necessary, it should have an explicit exit criterion rather than
leaving the feature permanently untested and disabled by default.
This topic has been public since July 23. Benoit has consistently supported the
hidden-visibility direction and has now suggested discussing it during next
Tuesday's call. Florin raised the global-data and out-of-tree concerns
discussed above.
I have also discussed this offline with Damjan. My understanding from those
exchanges was that he viewed the direction positively, but I do not want to
speak on his behalf and will leave him to state his position if he wishes.
The concrete RFC series was posted on August 26:
https://gerrit.fd.io/r/c/vpp/+/46571
https://gerrit.fd.io/r/c/vpp/+/46572
https://gerrit.fd.io/r/c/vpp/+/46573
I am happy to discuss this next Tuesday, as Benoit suggested. Before the call,
I propose to:
1. Add the standalone out-of-tree plugin checker and document its use.
2. Make the ABI-change analysis and methodology available to the community.
3. Ask reviewers to identify any remaining concrete technical issues on Gerrit
or the mailing list.
The goal of Tuesday's discussion should then be to resolve those remaining
points and reach a decision on the series, rather than defer the subject to
October.
Dave, since you mentioned that you would not be available for the two scheduled
September community meetings, could you please confirm whether you can attend
next Tuesday's discussion? If not, we can address your concerns in writing
beforehand and send you a concise summary of the outcome.
I believe the proposed changes address the practical compatibility concerns,
improve control over what libvnet intentionally exposes, and provide measurable
performance benefits, particularly on ARM. They also avoid introducing an
undocumented ABI requirement applied only to this patch.
Best regards,
Jerome
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#27170): https://lists.fd.io/g/vpp-dev/message/27170
Mute This Topic: https://lists.fd.io/mt/121139638/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
