On Sun, 27 Nov 2005, Daniel Ouellet wrote:
> 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
That's a misunderstanding: pf does not route, it's the ip layer code
in the kernel. Hint: routing existed before anybody even though of firewalls.
> 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
Indeed, if the route deamon does nothing, only the kernel is doing
work. In general the work being done will be something like:
Interface receives a packet, driver puts it on queue, ip layer picks
up packet, decides on route, puts it on queue and kicks the driver of
the outgoing interface, which sends it out. If pf ius active, it will
do its thing too, of course.
> 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?
As Henning said, in some cases interrupt processing on MP machines
might be faster.
> 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?
Yes, if the routing daemon is idle you are right. But in practise the
routing daemon will be active, and the impact on performance will be
hard to predict, bcause it is very much dependant on a lot of things.
>
> 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.
-Otto
