[j-nsp] Multi Core on JUNOS?

[Adam Chappell]

On 8 October 2015 at 17:46, Saku Ytti <saku at ytti.fi> wrote:

>
> Hard step#3 is to make rpd use multiple cores. JNPR seems to choose to
> DIY inside rpd and just launch threads. I personally would like to see
> rpd distributed to multiple OS processes, and capitalise more on
> FreeBSD's memory management and scheduling. But I'm not sure how to
> handle the IPC efficiently without large cost in data duplications
> across processes.
>
>
I can imagine that making rpd MT is probably hard to the point of almost
not being worth the benefit (with current REs), unless one can adequately
break down the problem into divisable chunks of work that are insensitive
to execution order.  BGP peer route analysis, comparison against import
policy and current RIB might fall into that category, but not without a lot
of locking and potential for races.

I think there's more bang for buck in the 64-bit address space change what
with Internet FIB table size, and I'm quite interested in the developments
to make rpd 64-bit clean which I'm sure are also not insignificant. I
notice Mr Tinka already expressed a conservative view on jumping into a
64-bit rpd and I can totally understand and appreciate that view. Juniper
haven't made this a default on the 14.1R5 cut of code that we're currently
testing, so I imagine they're still looking for bleeding-edge feedback to
whittle out the potential nasties.

I'm quite intrigued by the tidbit in the Juniper docs, though, that
suggests that switching from a 32-bit to a 64-bit rpd is not service
affecting though which means that the wait-and-see approach is viable?  Or
am I totally misunderstanding this?

https://www.juniper.net/documentation/en_US/junos14.1/topics/reference/configuration-statement/routing-edit-system-processes.html

It doesn't say that one needs NSR or any sort of "help" from the backup RE
which might be the first assumption. So I wonder how they manage to get one
process to exit and the other one to start up with different runtimes,
differently sized pointers etc., and somehow share the same in-core RIB and
protocol state etc etc.? If this really does work, there's probably someone
sitting somewhere in Sunnydale immensely smug and under-stated right now,
and if so I'm sure he/she'd eat the MT problem for breakfast!

-- Adam.