From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 13:34:49 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5079916A418; Thu, 3 Jan 2008 13:34:49 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 119B413C44B; Thu, 3 Jan 2008 13:34:49 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 92B818296B; Thu, 3 Jan 2008 08:34:48 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 03 Jan 2008 08:34:48 -0500 X-Sasl-enc: HqL3WxBJaqol0Umex0Nr6hBA7145Jo0dMFHsL7Ox5GKt 1199367287 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 5C62F27497; Thu, 3 Jan 2008 08:34:47 -0500 (EST) Message-ID: <477CE476.9000205@FreeBSD.org> Date: Thu, 03 Jan 2008 13:34:46 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Andre Oppermann References: <43B45EEF.6060800@x-trader.de> <43B47CB5.3C0F1632@freebsd.org> <477C1434.80106@freebsd.org> <477C1776.2080002@FreeBSD.org> <477C25E2.4080303@freebsd.org> In-Reply-To: <477C25E2.4080303@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Tiffany Snyder , Julian Elischer Subject: Re: Routing SMP benefit 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, 03 Jan 2008 13:34:49 -0000 Andre Oppermann wrote: > Haven't looked at the multicast code so I can't comment. The other > stuff is just talk so far. No work in progress, at least from my side. Insofaras rmlocks and cache line size vs rtentry size applies to multicast: I know there are implementations out there which use the unicast BSD routing code to do multicast. This is preferable as the MROUTING implementation in the main tree has a 32 vif limitation. Moving this into the main radix trie code allows us to overcome these limitations. Recall that a multipath FIB holds multiple next-hops for each route. Multicast routes need the same, but they also need to send traffic to all of the next-hops. This is basically what the MROUTING code does, but it does so completely separately from the unicast forwarding code. The reasons for this are mostly historical -- folks wanted to develop it separately from unicast IPv4. For IETF MANET, ie tactical mobile IP networks, we need to be able to address multicast next-hops by their unicast address -- most of the time we can't reliably use link layer multicast or even IGMP to reach all subscribers, or use PIM shared trees, so flooding is necessary -- as well as being able to disable the existing RPF checks on inbound traffic from MANET interfaces. In situations like this, 32 next-hop I'm aware this is only marginally related to the DFZ/tier-1 router scenario, but, it's something I want FreeBSD to support as it allows IP networks to be deployed in novel situations i.e. where no existing infrastructure exists, and centralized/hierarchical network infrastructure isn't suitable (think International Rescue). So it's something to think about for folks doing multipath work -- the same performance constraints which affect struct rtentry *now* for SMP and multipath work will potentially affect multicast forwarding in future. regards BMS