From owner-freebsd-hackers  Sun Jul  1 10: 0:37 2001
Delivered-To: freebsd-hackers@freebsd.org
Received: from tonnant.cnchost.com (tonnant.concentric.net [207.155.248.72])
	by hub.freebsd.org (Postfix) with ESMTP
	id 7EA1137B401; Sun,  1 Jul 2001 10:00:29 -0700 (PDT)
	(envelope-from bakul@bitblocks.com)
Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216])
	by tonnant.cnchost.com
	id NAA07500; Sun, 1 Jul 2001 13:00:19 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.14]
Message-ID: <200107011700.NAA07500@tonnant.cnchost.com>
To: Wes Peters <wes@softweyr.com>
Cc: Ruslan Ermilov <ru@FreeBSD.org>, Deepak Jain <deepak@ai.net>,
	net@FreeBSD.org, hackers@FreeBSD.org
Subject: Re: fastforwarding? 
In-reply-to: Your message of "Wed, 27 Jun 2001 22:39:20 MDT."
             <3B3AB4F8.184A2EFE@softweyr.com> 
Date: Sun, 01 Jul 2001 10:00:19 -0700
From: Bakul Shah <bakul@bitblocks.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-hackers.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-hackers>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-hackers>
X-Loop: FreeBSD.ORG

> > What does the fastforwarding option do that the normal forwarding option
> > doesn't?

> The description there isn't very forthcoming.  fastforwarding caches
> the results of a route lookup for destination addresses that are not
> on the local machine, and uses the cached route to short-circuit the
> normal (relatively slow) route lookup process.  The packet flows 
> directly from one layer2 input routine directly to the opposing 
> layer2 output routine without traversing the IP layer.

You do have to look at the destination ip address so strictly
speaking the cache belongs to the ip "layer".  I haven't
looked at this fastforwarding code but it likely complicates
route adding/deleting at you have to look at it for *any*
route add/delete.  For example, for dest addr 1.2.3.4, you
cached the result of route lookup (which may be 1.2.x.x/16)
and now a route for 1.2.?.x/24 is added.  You may have to
invalidate the cache entry since the new route may have to be
used.  Similarly for deletes.  Even the old single entry
cache in the std 4.4bsd had/has a related bug.

IMHO you are better off using a recent route lookup algorithm
than messing with caches.  The PATRICIA tree algorithm is
what 33 years old now?  There has been a lot of research done
in this area in the last few years.  On a modern machine with
some of the recent algorithms you should be able to easily do
a lookup in a just a few memory accesses.  The changeover is
not easy and quite pervasive in the networking code but long
overdue.  If anyone decides to do this, please make the
changes so that any algorithm can be pluuged in.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message