-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bgp_process work #15572
bgp_process work #15572
Conversation
@@ -327,6 +327,7 @@ struct bgp_path_info { | |||
#define BGP_PATH_ACCEPT_OWN (1 << 16) | |||
#define BGP_PATH_MPLSVPN_LABEL_NH (1 << 17) | |||
#define BGP_PATH_MPLSVPN_NH_LABEL_BIND (1 << 18) | |||
#define BGP_PATH_UNSORTED (1 << 19) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it mean: that if bgp_path_info
is not evaluated yet as the best path, it's marked as UNSORTED, otherwise - SORTED. But it's not related to the actual sorting of the paths in bgp_dest
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes this is just a tag that tracks whether or not a path_info has had best path run over it at all.. Unsorted was just choosen as a name because I think of it that way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
0369cb8
to
b494b7a
Compare
Just a curious question: is there any performance degradation or not at all? |
I have not done that testing yet. My expectation though is that it should be neutral at this point in time. My next set of improvements is to use the sorted order to do faster multipath calculations. |
b494b7a
to
3b6459a
Compare
CI:rerun Rerun after fixing git access on CI infra |
3b6459a
to
034a318
Compare
Signed-off-by: Donald Sharp <[email protected]>
Signed-off-by: Donald Sharp <[email protected]>
Modify update_evpn_type5_route_entry to return a pointer to the struct bgp_path_info modified in this function. This code merely follows the standards used in other bgp_evpn.c code where the update function returns the pointer to the path info. Signed-off-by: Donald Sharp <[email protected]>
This is seriously indented. Let's make it a bit better. Signed-off-by: Donald Sharp <[email protected]>
Add a debug function to allow developers to dump flags associated with a bgp_path_info in a human readable format. Signed-off-by: Donald Sharp <[email protected]>
Add a new flag BGP_PATH_UNSORTED to keep track of sorted -vs- unsorted path_info's. Add some ability to the system to understand when that flag is set. Signed-off-by: Donald Sharp <[email protected]>
bgp_damp.c has an instance of bgp_path_info_delete is called. Thus setting up the path info for deletion, but since it never calls bgp_process, it can never be deleted. This means that in a dampening situation, after a withdrawal the path_info would stick around. Schedule the path for deletion. Signed-off-by: Donald Sharp <[email protected]>
This will allow a consistency of approach to adding/removing pi's to from the workqueue for processing as well as properly handling the dest->info pi list more appropriately. Signed-off-by: Donald Sharp <[email protected]>
Currently evpn code calls bgp_best_selection for local decisions for local tables to figure out what to do. This is also pi based so let's note that the pi has been changed before calling bgp_best_selection. Signed-off-by: Donald Sharp <[email protected]>
Do not reap instead let's schedule for deletion and let best_path_selection take care of the deletion as it should. Signed-off-by: Donald Sharp <[email protected]>
034a318
to
f099883
Compare
Currently bgp_path_info's are stored in reverse order received. Sort them by the best path ordering. This will allow for optimizations in the future on how multipath is done. Signed-off-by: Donald Sharp <[email protected]>
f099883
to
f3575f6
Compare
Why I did it Added patches from FRR to support scale of BGP neighbors to 256/514. Below are the patches Patch FRR Pull request 0069-lib-nexthop-code-should-use-uint16_t-for-nexthop-cou.patch FRRouting/frr#16967 0070-Allow-16-bit-size-for-nexthops.patch FRRouting/frr#17023 0071-zebra-Only-notify-dplane-work-pthread-when-needed.patch FRRouting/frr#17062 0072-Fix-up-improper-handling-of-nexthops-for-nexthop-tra.patch FRRouting/frr#17076 0073-remove-in6addr-cmp.patch FRRouting/frr#17312 0074-bgp-best-port-reordering.patch FRRouting/frr#15572 0075-bgp-mp-info-changes.patch FRRouting/frr#16961 0076-Optimizations-and-problem-fixing-for-large-scale-ecmp-from-bgp.patch FRRouting/frr#17229
…net#21199) Why I did it Added patches from FRR to support scale of BGP neighbors to 256/514. Below are the patches Patch FRR Pull request 0069-lib-nexthop-code-should-use-uint16_t-for-nexthop-cou.patch FRRouting/frr#16967 0070-Allow-16-bit-size-for-nexthops.patch FRRouting/frr#17023 0071-zebra-Only-notify-dplane-work-pthread-when-needed.patch FRRouting/frr#17062 0072-Fix-up-improper-handling-of-nexthops-for-nexthop-tra.patch FRRouting/frr#17076 0073-remove-in6addr-cmp.patch FRRouting/frr#17312 0074-bgp-best-port-reordering.patch FRRouting/frr#15572 0075-bgp-mp-info-changes.patch FRRouting/frr#16961 0076-Optimizations-and-problem-fixing-for-large-scale-ecmp-from-bgp.patch FRRouting/frr#17229
…net#21199) Why I did it Added patches from FRR to support scale of BGP neighbors to 256/514. Below are the patches Patch FRR Pull request 0069-lib-nexthop-code-should-use-uint16_t-for-nexthop-cou.patch FRRouting/frr#16967 0070-Allow-16-bit-size-for-nexthops.patch FRRouting/frr#17023 0071-zebra-Only-notify-dplane-work-pthread-when-needed.patch FRRouting/frr#17062 0072-Fix-up-improper-handling-of-nexthops-for-nexthop-tra.patch FRRouting/frr#17076 0073-remove-in6addr-cmp.patch FRRouting/frr#17312 0074-bgp-best-port-reordering.patch FRRouting/frr#15572 0075-bgp-mp-info-changes.patch FRRouting/frr#16961 0076-Optimizations-and-problem-fixing-for-large-scale-ecmp-from-bgp.patch FRRouting/frr#17229
…net#21199) Why I did it Added patches from FRR to support scale of BGP neighbors to 256/514. Below are the patches Patch FRR Pull request 0069-lib-nexthop-code-should-use-uint16_t-for-nexthop-cou.patch FRRouting/frr#16967 0070-Allow-16-bit-size-for-nexthops.patch FRRouting/frr#17023 0071-zebra-Only-notify-dplane-work-pthread-when-needed.patch FRRouting/frr#17062 0072-Fix-up-improper-handling-of-nexthops-for-nexthop-tra.patch FRRouting/frr#17076 0073-remove-in6addr-cmp.patch FRRouting/frr#17312 0074-bgp-best-port-reordering.patch FRRouting/frr#15572 0075-bgp-mp-info-changes.patch FRRouting/frr#16961 0076-Optimizations-and-problem-fixing-for-large-scale-ecmp-from-bgp.patch FRRouting/frr#17229
…net#21199) Why I did it Added patches from FRR to support scale of BGP neighbors to 256/514. Below are the patches Patch FRR Pull request 0069-lib-nexthop-code-should-use-uint16_t-for-nexthop-cou.patch FRRouting/frr#16967 0070-Allow-16-bit-size-for-nexthops.patch FRRouting/frr#17023 0071-zebra-Only-notify-dplane-work-pthread-when-needed.patch FRRouting/frr#17062 0072-Fix-up-improper-handling-of-nexthops-for-nexthop-tra.patch FRRouting/frr#17076 0073-remove-in6addr-cmp.patch FRRouting/frr#17312 0074-bgp-best-port-reordering.patch FRRouting/frr#15572 0075-bgp-mp-info-changes.patch FRRouting/frr#16961 0076-Optimizations-and-problem-fixing-for-large-scale-ecmp-from-bgp.patch FRRouting/frr#17229
See individual commits. But setup for best path reordering. Code cleanup etc.