Routing SMP benefit
Bruce M. Simpson
bms at FreeBSD.org
Thu Jan 3 05:34:49 PST 2008
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.
More information about the freebsd-net