Henning Brauer wrote:
* Daniel Ouellet <[EMAIL PROTECTED]> [2005-11-26 08:57]:
Looking at the code of bgpd/ospfs, I don't see it design as using multiple treads ( doesn't mean I understand it fully either) so it wouldn't benefit from a dual core server then, and as the routing table basically is process by the kernel, I would think it would be useless to have multi core no?



bgpd and ospfd are not threaded at all, on purpose.

however, they are multiple processes. in case of bgpd, the session engine and the parent process on one CPU and the RDE on the other should give performance benefits. and you're not only doing bgpd, you are also forwarding packets, so MP might really improve your total performance.


I thought about this, but I am still not sure that it would benefit. I didn't asked before on Otto answer where:

"If you run a routing daemon, and are doing routing your are doing
multiple things simultaneously: an application (which in some cases
consists of multiple processes) and the kernel both do work"

Isn't it that all the routing changes anyway, either from BGPd or OSPFd are both ending in the PF table at the kernel level. That's what I understand anyway and unless I miss something PF in that case would be the party making the routing here and PF been single tread and looking at the process list, I don't see multiple pf processes, so the routing would be a linear process so multi core, or even multi processor wouldn't really help for that. Yes, they could for BGP session flap, etc. But that's about it no? In short, it the setup was perfect ( no such thing obviously) meaning no route changes for flap, but only for new additions of networks, etc. The routing table wouldn't change and as such the process would be PF doing the work in a linear fashion making the use of multi core, or multi processor useless in that case, or may be even negatively impact it?

I agree that there might be something I don't understand that may affect this and that's why I try to see what may change that, but other then small process doing very little to start with and some changes to routing table because of flap, the routing itself of moving packets around wouldn't benefit, or may actually be impair par the scheduling of process no?

I know this is a very remote question, but I am trying to make sure I understand it right. That's what I thought above anyway, is it right or wrong?

Daniel

PS: Don't get me wrong, one OpenBSD router kills many times over a good size Cisco one, no questions there! But I am more interested in the efficiency of OpenBSD itself compare it itself as an understanding of how things work under the hood.

Reply via email to