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>

diff --git a/bgpd/bgp_nht.c b/bgpd/bgp_nht.c
index 164e2300c09ed190c4ea68d7a634f5cd25e391f2..2ef7ec97e3fe5fbfae525b478041c05177cdbe17 100644 (file)
--- a/bgpd/bgp_nht.c
+++ b/bgpd/bgp_nht.c
@@ -1278,6 +1278,25 @@ void evaluate_paths(struct bgp_nexthop_cache *bnc)
        }
 
        LIST_FOREACH (path, &(bnc->paths), nh_thread) {
+               /*
+                * Currently when a peer goes down, bgp immediately
+                * sees this via the interface events( if it is directly
+                * connected).  And in this case it takes and puts on
+                * a special peer queue all path info's associated with
+                * but these items are not yet processed typically when
+                * the nexthop is being handled here.  Thus we end
+                * up in a situation where the process Queue for BGP
+                * is being asked to look at the same path info multiple
+                * times.  Let's just cut to the chase here and if
+                * the bnc has a peer associated with it and the path info
+                * being looked at uses that peer and the peer is no
+                * longer established we know the path_info is being
+                * handled elsewhere and we do not need to process
+                * it here at all since the pathinfo is going away
+                */
+               if (peer && path->peer == peer && !peer_established(peer->connection))
+                       continue;
+
                if (path->type == ZEBRA_ROUTE_BGP &&
                    (path->sub_type == BGP_ROUTE_NORMAL ||
                     path->sub_type == BGP_ROUTE_STATIC ||