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

[Bruce Simpson]

Simon van der Linden wrote:
>
> I'm not sure to follow you. On the one hand, you mention 
> Boost.Interprocess, to use processes instead of threads. How would 
> communication with other processes through XRL work in this case?

You still need to serialize access to shared data structures.

I haven't looked under the hood at how Boost.Interprocess does it, 
however they are probably using the fairly common practice of generation 
numbers on shared structures to determine when a race has been lost, and 
the shared variable needs to be re-read.

However, if you're focused purely on BGP itself, then your original 
strategy is likely to work; please see further down.

>
> On the other hand, you mention Boost.ASIO, which implements features 
> similar to what libxorp does but in a thread-safe way. In this case, 
> adapting all the XORP stack would be needed.

Exactly. It can be used in new processes, up to a point, but involves a 
rethink.

Moving XRL to Thrift is pretty much a requisite change here.

People on thrift-users@ have already successfully ported the Thrift C++ 
client library to use Boost.ASIO for non-blocking operation; there are 
two such patch sets.

>
> And eventually, you mention uC++, which provides advanced concurrent 
> structures on top of C++. It doesn't seem that those abstractions 
> would leverage the need for a thread-safe library to replace current 
> libxorp and libxipc though.

Exactly. uC++ is worth a look for conceptual ideas, but it isn't going 
to solve problems in the here and now.

>
> Is this correct?
>
> Regarding my thesis, which solution you think would be feasible in a 
> 4-month timeframe starting next February, keeping in mind that 
> bringing threading support in XORP is not the ultimate goal?

I don't mean to blow your mind. :-)

Thanks for clarifying that BGP itself would be used as the mechanism for 
dividing BGP's work across cores. This is likely to be easier to deal 
with, and it's something that can probably achieved in your time frame.

I would point out, however, that XORP's BGP process does its own socket 
I/O at the moment, unlike the other XORP processes.

When I looked at Boost.ASIO as a replacement for socket I/O management 
within the FEA, it quickly became clear that its socket support wasn't 
up to bleeding edge in terms of the hooks we need for things like 
multicast, broadcast, link-layer.

But for unicast, stream socket I/O, as found in BGP, it should be just fine.

cheers,
BMS