-
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
zebra, lib: use internal rbtree for per-NS tree of ifps #17297
base: master
Are you sure you want to change the base?
Conversation
Make an MTYPE used in zifs internal/static Signed-off-by: Mark Stapp <mjs@cisco.com>
Add new per-NS interface typerb tree, using external linkage, to replace the use of the if_table table. Add apis to iterate the per-NS collection - which is not public. Signed-off-by: Mark Stapp <mjs@cisco.com>
Replace use of the old if_table with the new per-NS ifp iteration apis. Signed-off-by: Mark Stapp <mjs@cisco.com>
Add an include to an isis header so it's self-contained. Signed-off-by: Mark Stapp <mjs@cisco.com>
Remove use of the per-NS if_table from zebra/interface module. Use new add, lookup, and iteration apis. Signed-off-by: Mark Stapp <mjs@cisco.com>
Use the new per-NS interface iteration apis in the evpn module. Signed-off-by: Mark Stapp <mjs@cisco.com>
Finish removing the table route_node from the ifp struct. Signed-off-by: Mark Stapp <mjs@cisco.com>
Replace use of the old if_table with the new per-NS ifp iterator apis in the zebra vxlan code. Signed-off-by: Mark Stapp <mjs@cisco.com>
Finish removing the if_table from the zebra NS struct. Signed-off-by: Mark Stapp <mjs@cisco.com>
296ed22
to
b7263c0
Compare
pushed to fix shutdown-time cleanup |
|
||
zif = ifp->info; | ||
if (!zif || zif->zif_type != ZEBRA_IF_VXLAN) | ||
goto done; |
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.
why goto here? Especially since we have other returns directly in the middle?
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.
just an artifact of moving the code from the inline loop to the callback I guess. we need to be able to have "special" continue path for this clause, and then the "normal" continue path for non-error cases at the end of the callback?
|
||
if (in_param->bridge_vlan_aware) { |
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.
where did this test go to? I'm confused about the fairly big change in this function.
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.
heh - yeah, there are a couple of examples of this. this clause only uses info from the top-level call - it doesn't need to be part of the iteration at all, so I moved it to the caller, the function that starts the iteration.
Replace the "lib/table" based per-NS collection of interfaces with a dedicated rbtree. Convert all the code that uses the if_table directly to use new iterator apis.