resend: multiple routing table roadmap (format fix)

[Vadim Goncharov]

07.01.08 @ 03:41 Andre Oppermann wrote:

> Vadim Goncharov wrote:
>> 07.01.08 @ 00:10 Julian Elischer wrote:
>>
>>>>> Is multicast and multipath routing the same?
>>>>  No. They are currently orthogonal.
>>>>  However it makes sense to merge the multicast and unicast forwarding  
>>>> code as currently MROUTING is limited to a fan-out of 32 next-hops  
>>>> only. In multicast, next-hops are normally just interfaces.
>>>>  Also the IETF MANET ad-hoc IP is going to need hooks there;  
>>>> multicast in MANET needs to address its next-hops by their unicast  
>>>> address, and encapsulate the traffic with a header. This is not true  
>>>> link layer multicast -- although it might use link layer multicast to  
>>>> leverage the hash filters in 802.11 MACs.
>>>>  As regards getting ARP out of forwarding tables, this should have  
>>>> happened a long time ago...
>>>
>>> I'm not 100 % convinced of this...
>>> I was, but I think there may still be a place for a cached arp pointer
>>> in hte next hop route to the arp entry for that next hop.
>>> I DO however thing that the arp stuff should nto be accessing its
>>> data via the routing table.
>>  Surely, routing table should contain a cached pointer to an entry in  
>> L2 table (ARP in case of Ethernet), to not do double lookups. But still  
>> separate those tables...
>
> Locking hell over again.  How do you remove an ARP entry without doing
> a full walk over the entire routing table (some 250K entries for the
> DFZ)?  Make it rmlocks and be done with it.

Why a full walk, why such a dumb way? To remove an ARP entry for host  
A.B.C.D in L2 table of form (A.B.C.D -> 00:01:02:03:04:05), it is enough  
to do a (usual speed) routing lookup for host A.B.C.D and modify a one  
pointer in it's rtentry to NULL or remove rtentry (if it's selected to be  
implemented as cloned). Thus, when on regular forwarding (table read) a  
routing lookup is done, we already have a FAST access - one pointer  
dereference - for it's L2 table entry, be it ARP or any other L2 type  
(which support becoming easily with separation of L2 and L3). And on every  
modification of L2 table - which is RARE - do lookup with usual speed to  
modify cached pointer. Compare it with a scheme where for EVERY forwarded  
packet, there is a need for DOUBLE lookup - after a routing one, do  
another in L2 table.

Current routing table implementation, with all disadvantages of combining  
L2 and L3, have from the same combinig a one HUGE benefit - performance.  
And never, ever, ever, ever even try to split L2 from L3 with losing that  
performance - then it should be still never split, despite all  
disadvantages, and you'll become an enemy of many, many users. Especially  
while caching allows to do things reasonably fast.

-- 
WBR, Vadim Goncharov