Re: (diet-)FIB alternative fib_hlist.c

[Robert Olsson <Robert.Olsson@data.slu.se>]

Andi Kleen writes:

 > Great patch! I wanted to do something like this for a long time :/
 > It is a good solution for 99.999% of all users who never have more
 > than a few routes.
 > 
 > Random comments while reading the code:
 > 
 > I would perhaps add a printk that warns the user if there are
 > more than 10 routes or so to use a different FIB.

 When we find the break-even point we can a print warning at insertions
 above this point. A minor problem.

 > Also I would try to replace the write locks with normal spinlocks.
 > read/write locks should not be needed for the use case of a normal
 > client who basically never changes the routing table, and normal
 > spinlocks are more friendly to modern cache coherency protocols.

 Interesting. I'll guess this goes for all FIB variants. Needs some 
 experimentation.

 > With only a few routes it is overkill to have two kmem caches,
 > which both need at least a page each. With 10-20 routes you
 > waste half the memory because of that. Better use a single 
 > slab cache for both object types or just kmalloc.

 Doable. slab objects are nice & easy to monitor during development.

 > Now we only need support for loadable fibs, then
 > distributions could use this too. Loadable ones should
 > be pretty easy, as long as you dont try to make them unloadable.

  First step yes. Also we need hi-pref system to have multiple 
  FIB variants. Just attack it if got some ideas.

 > The later would need a lot of reference counting in fast paths,
 > which would be probably a bad idea. And losing that capability
 > is not a big issue.

 Yes leave that out for now.

 Cheers.
					--ro