From owner-freebsd-hackers Sat Jun 24 14:13:39 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA25815 for hackers-outgoing; Sat, 24 Jun 1995 14:13:39 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA25808 for ; Sat, 24 Jun 1995 14:13:34 -0700 Received: from corbin.Root.COM (corbin [198.145.90.18]) by Root.COM (8.6.11/8.6.5) with ESMTP id OAA00885; Sat, 24 Jun 1995 14:13:35 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id OAA00135; Sat, 24 Jun 1995 14:13:58 -0700 Message-Id: <199506242113.OAA00135@corbin.Root.COM> To: Network Coordinator cc: hackers@freebsd.org Subject: Re: FreeBSD as a router In-reply-to: Your message of "Sat, 24 Jun 95 17:05:29 EDT." From: David Greenman Reply-To: davidg@Root.COM Date: Sat, 24 Jun 1995 14:13:58 -0700 Sender: hackers-owner@freebsd.org Precedence: bulk >So the problem is how to get BSD to handle packets faster. And I guess my >question still is, why can't we move some of the packet-handling and routing >directly into the driver where it is a few layers closer to the actual >hardware. Not really off loading, but giving the packet-handling code a >chunk of the CPU time (probably as much as it needs) w/o being able to be >squeezed out by other processes and such. If there is a way that can be found to do it in an architecturally clean way, then we may very do this...but is may not be necessary. I haven't had a chance to look carefully at where CPU is being spent when routing packets. On of these days... >There is a program called pc-route for DOS systems that supposedly is as >fat-free as code can be [no branches in the assembly source, etc]. On a >pentium with 2 100 mbps cards, I am wondering how fast it could move >packets to give a theoretical packet/s maximum. Anyone have a >configuration where they could try it? Last time I used pc-route, it crashed every 5-30 minutes. It's performance wasn't so hot, either. I haven't looked at it in a year or so, so perhaps the code has been improved. The main things that stick in my memory are that it was a black box, difficult to configure, impossible to troubleshoot, and had a broken RIP implementation. -DG