From: David Luyer <david_luyer@pacific.net.au>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Chris Crowther <chrisc@shad0w.org.uk>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] CDP handler for linux
Date: 15 Aug 2001 15:48:00 +1000 [thread overview]
Message-ID: <997854480.3451.10.camel@typhaon> (raw)
In-Reply-To: <E15WlHC-0001xF-00@the-village.bc.nu>
In-Reply-To: <E15WlHC-0001xF-00@the-village.bc.nu>
On 14 Aug 2001 21:59:02 +0100, Alan Cox wrote:
> > This said, if the consesus is that it belongs in userspace, I
> > shall set about porting the code over to a dameon and possibly maintaing
> > the kernel patch as a secondary "hobby project".
>
> I really think user space is the right place for it. That keeps it in
> pageable memory and likely to dump a core not an entire box on errors.
You're right (of course), but to a small extent it may depend how
critical CDP is to your routing. Both CDP and HSRP are things which
can be used by Ciscos to choose backup paths, but neither protocol is
really "urgent, real-time priority required" in the timing so that's
really the main reason to stay out of the kernel.
If you're using "set ip next-hop verify-availability" in a Cisco router
then you don't want CDP to fail unless the machine is unavailable to
route. But then I guess we don't have OSPF or BGP in the kernel, so CDP
doesn't belong there either.
One thing which would be nice though from a performance perspective is
a kernel NetFlow collector. I'm currently using a netflow collecter
which uses <asm/unistd.h> and doesn't link against libc or crt0.o,
accumulates all it's write()s as 128k chunks, etc, and that's damn fast,
but the kernel should be able to be even faster (avoid all those
context switches on each packet received).
--
David Luyer Phone: +61 3 9674 7525
Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693
Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 1111 2983
http://www.pacific.net.au/ NASDAQ: PCNTF
next prev parent reply other threads:[~2001-08-15 5:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-14 18:47 [PATCH] CDP handler for linux Chris Crowther
2001-08-14 19:30 ` Christoph Hellwig
2001-08-14 19:56 ` Chris Crowther
2001-08-14 20:59 ` Bjoern A. Zeeb
2001-08-14 20:17 ` Alan Cox
2001-08-14 20:54 ` Chris Crowther
2001-08-14 20:59 ` Alan Cox
2001-08-15 5:48 ` David Luyer [this message]
2001-08-14 21:07 ` Bjoern A. Zeeb
2001-08-14 21:32 ` Dan Hollis
2001-08-14 22:46 ` David S. Miller
2001-08-15 9:13 ` Chris Crowther
2001-08-15 9:23 ` David S. Miller
2001-08-15 9:32 ` Chris Crowther
2001-08-14 20:19 ` Dan Hollis
[not found] <Pine.LNX.4.33.0108141934130.3283-100000@monolith.shad0w.or g.uk>
2001-08-14 23:01 ` Lincoln Dale
2001-08-15 16:14 ` Chris Crowther
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=997854480.3451.10.camel@typhaon \
--to=david_luyer@pacific.net.au \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=chrisc@shad0w.org.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox