From owner-freebsd-net@FreeBSD.ORG Fri Jun 3 22:16:06 2005 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 6468916A41C for ; Fri, 3 Jun 2005 22:16:06 +0000 (GMT) (envelope-from lerik@nolink.net) Received: from electra.nolink.net (electra.nolink.net [195.139.204.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA17143D48 for ; Fri, 3 Jun 2005 22:16:05 +0000 (GMT) (envelope-from lerik@nolink.net) Received: (qmail 37135 invoked by uid 1000); 3 Jun 2005 22:16:01 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 3 Jun 2005 22:16:01 -0000 Date: Sat, 4 Jun 2005 00:16:01 +0200 (CEST) From: Lars Erik Gullerud To: Charlie Schluting In-Reply-To: <83946540050603135324d6b8cd@mail.gmail.com> Message-ID: <20050603235004.S25740@electra.nolink.net> References: <20050603181636.GA54906@gicco.homeip.net> <20050603191351.GA54164@ip.net.ua> <20050603202109.GA22098@gargantuan.com> <83946540050603135324d6b8cd@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: route metric 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: Fri, 03 Jun 2005 22:16:06 -0000 On Fri, 3 Jun 2005, Charlie Schluting wrote: > Reason #2 is latency. Vendor C put a lot of time and money into > features like CEF that take advantage of hardware packet forwarding. A > purely software-based device simply can't keep up with large flows, > and definitely introduces latency--especially when filtering. Just to set things straight, CEF != hardware packet forwarding. CEF is a forwarding/FIB-lookup algorithm that speeds up the packet forwarding by using a process to generate the complete FIB in a 256-way trie structure in memory from the routes in the RIB. This means the router can forward the packet a lot faster directly in the interrupt context when the packet is received on the ingress interface, as the trie lookup is a lot more efficient & requires fewer steps than older methods like building a route-cache based on recent lookups (usually stored in a radix tree). Case in point, the Cisco 7200, still one of the most widely deployed access/aggregation routers out there (especialy among small/medium-sized ISPs), is a pure CPU-based central forwarding architecture based on MIPS CPUs and PCI buses, which uses CEF central forwarding. Even many early 12000 GSR linecards merely distributed this function down to individual CPUs placed on the linecards (dCEF), they did not have hardware forwarding using ASICs/FPGAs. Yes, newer router models from all major vendors usually rely on ASIC-assisted forwarding, and increasingly more dataplane/controlplane separation but this has nothing to do with CEF as such. BTW, "large flows" are actually a lot easier to handle in CPU-based forwarding systems, as the limitation then usually lies in the available bus bandwidth. It's high packet rates that will kill these architectures quickly, due to the number of interrupts that need to be serviced and the number of individual FIB lookups this results in (even smaller routers handle large amounts of bandwidth if fed with large packet sizes and continuous flows). /leg