From owner-freebsd-hackers Sat Jul 1 10:30:17 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA25944 for hackers-outgoing; Sat, 1 Jul 1995 10:30:17 -0700 Received: from mail.htp.com (mail.htp.com [199.171.4.2]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA25938 for ; Sat, 1 Jul 1995 10:30:15 -0700 Received: from et.htp.com (et.htp.com [199.171.4.228]) by mail.htp.com (8.6.5/8.6.5) with SMTP id NAA16114 for ; Sat, 1 Jul 1995 13:28:54 -0400 Date: Sat, 1 Jul 1995 13:28:54 -0400 Message-Id: <199507011728.NAA16114@mail.htp.com> X-Sender: dennis@mail.htp.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-hackers@freebsd.org From: dennis@et.htp.com (dennis) Subject: Re: FreeBSD as a router 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. > The issue is not how to make BSD handle packets faster, but a question of priroities. Any optimization, say to improve local routing, will trade-off some performance elsewhere. When you add a filter, it improves one function but slows another. It seems that perhaps a good way to acheive this might be to build special-purpose drivers for direct interface-to-interface routing (which could be used instead of the regular driver when required) rather than to risk damaging the integrity of the op/sys architecture by implementing such hacks into the general drivers. db