[ppml] too many variables
Bruce M Simpson
bms at incunabulum.net
Sat Aug 25 00:41:51 UTC 2007
Hi,
I am the chap who did the port of XORP to Microsoft Windows; normally on
the Internet I play a FreeBSD committer role.
Leo Bicknell wrote:
> It seems to me an off the shelf PC with a Core 2 Duo processor, 4
> gig of memory, and a gigabit ethernet port would be 1-2 orders of
> magnitude faster than what's currently in the routers. Optimize
> for a multithreaded CPU, add a second and it would converge really
> fast. My own experience is that zebra / quagga blow away the
> performance of any router out there as long as you don't ask them
> to install the routes in the kernel (which is really slow in a
> general purpose OS).
>
As far as I am aware, zebra/quagga uses a table scanning design for BGP.
This is where XORP comes in:
http://www.usenix.org/event/nsdi05/tech/full_papers/handley/handley_html/index.html
Figure 13, BGP route flow, may be of particular interest here. XORP
defers the pushdown of routes in its RIB to the kernel.
The current model is to explicitly coroutine on a per-process basis,
within a message-passing architecture. This is lockless at process level
- the kernel handles synchronization based on the I/O primitives upon
which the XRL message passing between XORP routing processes is based,
so it does rely on the atomicity of these operations. Normally on a BSD
or Linux machine, a local stream socket (TCP or UNIX) is used for such
communication.
XORP's design could potentially be improved further for multi-core CPUs,
by the use of continuations and CPU affinity. The use of a
soft-real-time scheduler might also be worth investigation, although
XORP is built around cooperative multi-tasking, so that would require
explicitly re-entering the scheduler.
As regards the latency of route propagation to the kernel: I'd be
interested to hear in technical detail problems which people may be
experiencing here, e.g. on Linux or BSD platforms.
I have on-and-off been researching a new routing implementation for
FreeBSD which would draw inspiration from the recent work in Linux and
other operating systems, so I want to get as much input from people's
experiences as possible.
regards,
BMS
More information about the NANOG
mailing list