Routing SMP benefit

[Bruce M. Simpson]

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