bgpd: Optimize evaluate paths for a peer going down #17924
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
Currently when a directly connected peer is going down BGP gets a call back for nexthop tracking in addition the interface down events. On the interface down event BGP goes through and sets up a per peer Q that holds all the bgp path info's associated with that peer and then it goes and processes this in the future. In the meantime zebra is also at work and sends a nexthop removal event to BGP as well. This triggers a complete walk of all path info's associated with the bnc( which happens to be all the path info's already scheduled for removal here shortly). This evaluate paths is not an inexpensive operation in addition the work for handling this is already being done via the peer down queue. Let's optimize the bnc handling of evaluate paths and check to see if the peer is still up to actually do the work here. Signed-off-by: Donald Sharp <[email protected]>
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.
Currently when a directly connected peer is going down BGP gets a call back for nexthop tracking in addition the interface down events. On the interface down
event BGP goes through and sets up a per peer Q that holds all the bgp path info's associated with that peer and then it goes and processes this in the future. In the meantime zebra is also at work and sends a nexthop removal event to BGP as well. This triggers a complete walk of all path info's associated with the bnc( which happens to be all the path info's already scheduled for removal here shortly). This evaluate paths
is not an inexpensive operation in addition the work for handling this is already being done via the
peer down queue. Let's optimize the bnc handling
of evaluate paths and check to see if the peer is
still up to actually do the work here.