bgpd: Optimize evaluate paths for a peer going down

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 <sharpd@nvidia.com>

0 files changed, 0 insertions, 0 deletions