On 8 October 2015 at 17:46, Saku Ytti <s...@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. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp