On Fri, 15 May 2015, Vipin Kumar wrote:
So, IMO, we have a couple of choices:
(A)
Make this feature truly global to BGP deamon by moving the update-delay
config at the level where 'bgp multi-instance' is configured.
Unfortunately, there is a catch in this approach, the feature is currently
supported for 'clear ip bgp *' too, which can clear one view at a time. So,
with the current patch clearing one view can temporarily hold other views
best-paths/updates.
OR
(B)
Keep the config where it is, but fix the implementation to make it per view.
This option means some surgery of the BGP code to make the process queues
per view etc. Which may (in future) anyways be needed for fairness reasons
across views.
Given the best use case of this feature is at the daemon start-up time,
I would say we can go with with option (A) for now.
I don't mind either.
Conceptually the queues could be per-table, rather than where they are
now. Course, adding queues potentially introduces fairness issues as you
note, which might need more work.
So maybe A is easier.
As an aside, the (struct bgp_process_queue) that gets created and queued
up may be redundant - you can get the same data by going through the
(struct bgp_node *). Then you can just route_node directly. Avoiding the
alloc/frees of the bgp_process_queue would be nice. Whether the savings in
the mallocs outweights the costs of walking through the data-structs to
get to afi/safi/bgp each time, and whether it's worth the churn, I don't
know. ;)
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
In this world, truth can wait; she's used to it.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
