[quagga-dev 7808] Re: (no subject)

John Kemp kemp at network-services.uoregon.edu
Wed Feb 24 15:33:35 GMT 2010

On 11/30/2009 08:02 PM, Adrian Chadd wrote:
> 2009/12/1 Chris Hall<chris.hall.list at highwayman.com>:
>> Michael Lambert wrote (on 30-Nov-2009 at 22:52):
>>> What would your thoughts be on making each view in bgpd its own thread?
>>> Could this improve performance as a route server?
>> A thread for each Route Server client would certainly allow it to use all
>> the processors at its disposal when updates arrive.  Since bgpd is
>> completely CPU bound when running as Route Server for 200-300 clients, I
>> think that would be a Good Thing.
>> However, to start with I shall be happy to get enough threads running to
>> eliminate the current problems with BGP sessions dropping, and with the CLI
>> stopping responding, when the thing gets busy.
> I'd suggest looking at mapping out the various tasks inside bgpd and
> see what relies on what. Blindly creating threads without knowing how
> they interact is going to lead down a path of fail. :)
> My proposal for this (which is why it was so expensive and time
> consuming) was to spend a lot more time teasing apart the internals
> into some semblence of a documented mess; then massage module
> boundaries into something useful for parallelism. I couldn't say off
> hand whether parallelism was best at one thread per peer; or one
> "general" thread and then one (or more) "RIB" threads per view as a
> starting point, etc, etc. Too much of the code relies on changes
> happening atomically to make any changes easy -and- stable. :)
> IMHO, 2c,
> Adrian
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev at lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-dev

This topic came up a bit in the route servers discussion at the latest 
NANOG meeting.
Presentation is here:


The primary points of optimizations for the BGP implementations seemed 
to be 1) making each peer session i.e. state/holdtime/keepalive operate 
in a thread or process and 2) having the
multiplexing operate in a more predictable manner.  (Not arguing 
for/against any of this, just

John Kemp (kemp at network-services.uoregon.edu)
RouteViews Engineer
help at routeviews.org

More information about the Quagga-dev mailing list