From owner-freebsd-net@FreeBSD.ORG Thu Jul 27 08:11:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A83D16A4DD for ; Thu, 27 Jul 2006 08:11:38 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7017943D46 for ; Thu, 27 Jul 2006 08:11:37 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 20756 invoked from network); 27 Jul 2006 08:04:18 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Jul 2006 08:04:18 -0000 Message-ID: <44C8753F.20905@freebsd.org> Date: Thu, 27 Jul 2006 10:11:43 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Blue References: <44C82AA4.30306@zyxel.com.tw> In-Reply-To: <44C82AA4.30306@zyxel.com.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [FreeBSD-6.1Release]About the removal of route cache in PCB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 08:11:38 -0000 Blue wrote: > Hi, all: > > I am wondering why the FreeBSD-6.1 version removes the route cache in > PCB (struct inpcbin in_pcb.h)? Does the removal do anything good? Or its > existence would have potential problems? 'Cause in my opinion, the > removal would only produce extra time when emitting a packet since the > routing table lookup is unavoidable. So there's must be a good reason > for the change. The routing table pointer was complicating the SMP locking of the kernel and had some other drawbacks. With the pointer route changes would not be picked up immediately but only when packets got lost and caused ICMP responses. And for that many full PCB table walks had to be done. Simplicity was chosen and the route pointer was removed. The tradeoff isn't really bad as for most hosts the routing table is really small containing only the default route and some ARP entries. A lookup there is pretty much always a cache only operation. Only the locking overhead for the routing table lookup adds in but we would have to do much of it anyway to increment the refcount on the rtentry to send the packet. On servers with many connections the routing table could get quite large because of all these cloned routes and consume valuable kernel memory. No more routes for PCB's are cloned after the change. -- Andre