evpn: fix quadratic evpn mac-mobility handling #2750
Merged
Conversation
This file contains 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
Tuetuopay
changed the title
|
Hi! The force push was to rebase atop the current |
|
I fixed the lint errors. |
This patch adds a special case in the destination hashmap for EVPN Type-2 routes, to index them by MAC address. This allows for direct access to the destination struct, instead of iterating over all destination and all paths. In effect, this replaces an iteration over all known paths by a quick lookup to the MAC, leaving only an iteration to multiple paths to the same MAC (e.g. multihoming or through multiple VNIs). The practical effect is a reasonable convergence time for large EVPN instances. - before: 6m 7s - after: 11s The comparison was performed on a Xeon Silver 4209T, and an EVPN instance comprising of 13k EVPN type-2 routes. The time is measured by comparing the timestamp of the first and the last routes logged by the cli's monitor mode. Given the extreme difference, no further work was done for a more accurate measurment.
|
Thanks, rebased. Oh, and noticed I forgot to remove the draft status. |
Tuetuopay
changed the title
|
thanks |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
This patch adds a special case in the destination hashmap for EVPN Type-2 routes, to index them by MAC address. This allows for direct access to the destination struct, instead of iterating over all destination and all paths. Such an access is performed for every EVPN Type-2 route received for EVPN MAC mobility handling.
In effect, this replaces an iteration over all known paths by a quick lookup to the MAC, leaving only an iteration to multiple paths to the same MAC (e.g. multihoming or through multiple VNIs).
The practical effect is a reasonable convergence time for large EVPN instances.
The comparison was performed on a Xeon Silver 4209T, and an EVPN instance comprising of 13k EVPN type-2 routes. The time is measured by comparing the timestamp of the first and the last routes logged by the cli's monitor mode.
Given the extreme difference, no further work was done for a more accurate measurment.
Discussion
From the short testing done, I have seen no adverse effect conflating routes with the same MAC address to the sameDestinationstruct. However, this is the point I want to attract attention to as I am not familiar enough with the GoBGP internals.After more testing, such a conflating resulted in incorrect
ListPathbehavior and most importantly route propagation, as only the best path between all of them to the same MAC were OK. It was then an issue as a MAC present in multiple VNIs led to only a single path.The implementation was changed to use RD+MAC as the destination key. For the MAC mobility usecase, an index was added mapping a MAC address to the set of RDs that announced this MAC, allowing to build the set of destination keys for listing the paths related to a MAC.
Thanks!