Hello Paul, Thanks for answer. I found out the previous commit on volatile/patch-tracking/8/proposed/ff-2016072001.
Despite I don't have the big picture ( I am not sure next hop tracking has a meaning for AFI_ETHERNET - at least I did not see NHT implementing it), It makes sense to initialise and reset those tables with AFI_ETHERNET. I think it is better than locking the NHT entry point with some defense code. So, I would ack it. Acked-by: Philippe Guibert <[email protected]> Best Regards, Philippe ---------- Forwarded message ---------- From: Paul Jakma <[email protected]> Date: Tue, Sep 6, 2016 at 12:34 PM Subject: Re: [quagga-dev 16051] Re: [PATCH] bgp: bgp_nexthop init/free AFI_ETHER related NH tables To: Philippe Guibert <[email protected]> Cc: Lou Berger <[email protected]>, [email protected] Hi Philippe, This is on top of the Cumulus NHT stuff, so nexthop tracking is event-driven and bgp_scan() is gone. Just doing the final CI testing now to get this all done and dusted. regards, On Tue, 6 Sep 2016, Philippe Guibert wrote: > On Mon, Sep 5, 2016 at 6:18 PM, Lou Berger <[email protected]> wrote: > > Hello Lou > >> --- >> + cache1_table[AFI_ETHER] = bgp_table_init (AFI_ETHER, SAFI_UNICAST); >> + cache2_table[AFI_ETHER] = bgp_table_init (AFI_ETHER, SAFI_UNICAST); > > > I don't see any bgp_scan() code calling those entries. > bgp_scan(AFI_ETHER, SAFI_UNICAST). > > So is this code really called, is it just provisioning, or is there > something more in the pipe ? > > Best Regards, > > Philippe > > _______________________________________________ > Quagga-dev mailing list > [email protected] > https://lists.quagga.net/mailman/listinfo/quagga-dev > -- Paul Jakma | [email protected] | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Revenge is a form of nostalgia. _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
