Bruce, Thanks a lot for your reply!
On 16/12/09 12:46, Bruce Simpson wrote: > Simon van der Linden wrote: >> 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. > > To be honest, I don't believe this approach is likely to scale well. > Crossing process boundaries is complex and expensive. > > Most of the contention is on the BGP-RIB-FEA path. To some degree, this > can mitigated by XRL batching, something which is in commercial XORP, > but not community XORP [yet]. > > Using another layer of XRL, or even other IPC, to achieve parallelism > within the existing architecture, is likely to be prohibitively > expensive, and probably blow away the benefits of scheduling across > multiple cores. Actually, in my mind, the dispatcher would mainly talk "BGP" with its processes: it'd slice the updates by prefix and send them to the processes in charge as BGP updates over TCP. The BGP processes shouldn't need to communicate to each other. This way, we should be able to take benefit of multiple processors. What I don't know yet though is whether the RIB/FEA would become a bottleneck, whenever all the BGP processes send their new decisions by XRL. -- 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
