[Xorp-hackers] Taking benefit of parallel processing in BGP

[Simon van der Linden]

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