Date: Thu, 03 Jan 2008 13:34:46 +0000 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-net@freebsd.org, Tiffany Snyder <tiffany.snyder@gmail.com>, Julian Elischer <julian@elischer.org> Subject: Re: Routing SMP benefit Message-ID: <477CE476.9000205@FreeBSD.org> In-Reply-To: <477C25E2.4080303@freebsd.org> References: <43B45EEF.6060800@x-trader.de> <43B47CB5.3C0F1632@freebsd.org> <b63e753b0712281551u52894ed9mb0dd55a988bc9c7a@mail.gmail.com> <477C1434.80106@freebsd.org> <477C1776.2080002@FreeBSD.org> <477C25E2.4080303@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?477CE476.9000205>