resend: multiple routing table roadmap (format fix)

[Bruce M. Simpson]

Vadim Goncharov wrote:
> 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.

ARP lookups will generally use a cheap hash once split. What's the problem?

The PATRICIA lookups are more expensive, to be sure. Don't forget, 
though, that with moving L2 info out of PATRICIA, those host routes 
disappear from the table too, and thus their overhead during the tree walk.

rmlocks for L2 and L3 are probably going to be cheaper compared to a 
global mutex.

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

I disagree. The architectural benefits of taking ARP cache entries out 
of the routing table seem quite clear to me.

Other implementations have done this and seen it bear fruit, and your 
argument here sounds like hyperbole rather than cogent and reasoned 
argument about why this shouldn't be done.

If you have grave doubts about this which the rest of us aren't seeing, 
publish benchmarks?

One place to start might be to take Qing's code, run with it, and look 
seriously at it in a profiler such as Valgrind. But I'm preaching to the 
choir here...

Cheers
BMS