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