Hi, I'm a computer engineering student from the UCLouvain (Belgium) and in the context of my master's thesis (a full-time 4-month project), I look at ways to improve the performance of routers' control planes by using multicore architectures.
I'm currently trying to use parallel processing to improve performance of the BGP decision process, especially when a vast number of updates for different prefixes have to be processed. I chose to work with XORP because it seemed well designed and some documentation was available. At first, I thought I could use threads inside the BGP process, but following a few readings and a discussion with Adam Greenhalgh from the UCL, I gave up: the underlying libraries are not thread safe, and making them thread-safe would be enough to complete a master's thesis :-) So, the other approach is to use multiple BGP processes instead, and to load-balance according to the prefixes, among which the decision process is independent. I'll add a dispatcher process before the pool of BGP processes. That dispatcher shall be visible from the peers as if there was only a single BGP process. For each peering, the dispatcher shall open a random local port and ask each BGP process to open an internal peering to that port. The dispatcher shall split each incoming update or withdraw and direct it toward the BGP processes that handle the prefixes. Outgoing updates should be sent as-is. The dispatcher shall be responsible for filling and managing the BGP process pool. Now comes the problem of the router's internal communication (XRL) involving the BGP process. In particular, we don't want BGP processes to initiate peerings with anyone else than the dispatcher, so XRLs whose destination are the BGP process shall be handled by the dispatcher first, and then possibly forwarded to the BGP process in charge. The dispatcher shall thus be registered with its own class name, and the BGP template of the rtrmgr modified accordingly. I haven't looked at the XRL mechanisms in details though, but I read somewhere that it was possible to address a process either by class name or by instance name. That might be another solution, where the dispatcher should be registered as the default target of the class. As you might have guessed, one of my criteria is to make as few changes as possible to the existing BGP process and to plug my dispatcher in front of it transparently. This currently is a pretty rough idea, and I have no experience with XORP. For now, I have implemented a process that is started instead of the BGP process and that is able to start the BGP process. I'd greatly appreciate any comment or advice and I'm looking forward to discussing this with you. Regards, -- Simon van der Linden Computer Science and Engineering Student INGI/EPL/UCLouvain _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
