zebra: clean up VRF handling by using dataplane provided vrf_id #20318
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
maxime-leroy
force-pushed
the
zebra_vrf_id_cleanup
branch
from
54daa00 to
df97d46
Compare
Contributor
Author
|
ci:rerun |
1 similar comment
Contributor
Author
|
ci:rerun |
zebra_if_dplane_ifp_handling() was reading dplane_ctx_get_ifp_table_id() for VRF events. In the netlink dplane backend, ifp_table_id is only set via netlink_vrf_change(), which is invoked from netlink_link_change() for RTM_NEWLINK VRF events. It is not set for RTM_DELLINK. The VRF delete path does not require table_id and should not depend on a dplane field that is unset for delete operations. Split VRF handling into interface_vrf_update() and interface_vrf_del() so: - add/update uses the dplane-provided table_id - delete only relies on the VRF identity Signed-off-by: Maxime Leroy <maxime@leroys.fr>
interface_vrf_change() was implicitly assuming that the VRF netdevice ifindex could be used as zebra's vrf_id. This assumption holds true for the Linux kernel dataplane, where the VRF ID is defined as the ifindex of the VRF interface, so this change does not alter kernel behavior. However, the dataplane API already exposes both concepts explicitly via dplane_ctx_get_ifindex() and dplane_ctx_get_ifp_vrf_id(ctx). Using the proper accessor avoids casting an ifindex to vrf_id_t and better respects the dataplane abstraction. On interface updates, the vrf_id provided by the dataplane is now used directly. On interface deletion (DELLINK), where the dataplane context may no longer carry vrf information, zebra relies on the existing ifp state keyed by ifindex. This is required for non-kernel dataplanes such as Grout (DPDK), where the VRF ID is not equal to the VRF interface ifindex. In that case, using the correct vrf_id fixes VRF handling between zebra and the Grout dataplane. Signed-off-by: Maxime Leroy <maxime@leroys.fr>
maxime-leroy
force-pushed
the
zebra_vrf_id_cleanup
branch
from
df97d46 to
c772877
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Zebra was implicitly assuming that the VRF netdevice ifindex could be used as the VRF identifier, leading to casts from ifindex to vrf_id_t. While this works with the Linux kernel dataplane, it does not respect the dataplane API, which exposes these identifiers as distinct concepts.
The code is updated to use the VRF identifier explicitly provided by the dataplane context and removes the need for casting ifindex to vrf_id_t. In addition, the VRF delete path is clarified by no longer reading unused dataplane fields, avoiding confusion about which identifiers are actually required.
There is no behavior change for the Linux kernel dataplane.