resend: multiple routing table roadmap (format fix)

[Li, Qing]

> 
> Why a full walk, why such a dumb way? 
>

  Correct, we don't do a full walk. 

>
> 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.
> 

  Is it really a double lookup though ?  

  With the current routing table that contains the ARP entries,
  a search has to proceed pass the interface route further down 
  the routing tree, and the depth depends on the number of ARP 
  entries in the table.

  With L2/L3 seperation, the routing search stops at the interface
  route, and further search for the exact entry continues
  in a separate L2 table.

  From a high level it does seem there could be performance
  issues such as cache invalidation problem, however, I cannot
  quantify at this point what that degration translates into, 
  and what impact it has on the overall scheme of things.
  I am not sure if anyone can quantify such performance question
  at this point.

>
> 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.
> 

   No disagreement here.

   -- Qing