Darren,
We need to work within the existing IRE Multi-threading framework. Note that this framework was designed for hash list based IRE tables. Also note that the ire cache tables are still hash table based. So yes we will have both radix trees and hash tables as of now. Thirumalai Darren Reed wrote:
Now that I look more closely at one particular use of rn_walktree, that for deleting an entry (and the resulting call to ire_delete), we need to make this better. It seems insane that we're getting a lock on the tree, releasing it so we can call ire_delete that then locks it and releases it again. This seems like walking further down the path of insanity. Can we make this better? One path might be to require all callers of ire_delete to make sure that they have the radix tree locked before calling. You might even want to pass in a pointer to the radix tree itself, rather than use the ipftable global. This would be a step in the direction of making this part of the code able to work with multiple radix trees (c.f stack instances.) The catch here is that ire_delete_common() can call ire_delete_v4() which can then call ire_delete_host_redirects() which is where we began or am I going crazy? Can I point out that naming a function "rtfunc" is especially bad? Could this be at least "ire_rtfunc"? I thought this was a typo (given the other "rtfunc" bits around it) until I went searching %-( Thiru/Sangeeta - is it worth scheduling some time this week to get together and try come up with some ideas to untangle this mess? It seems like we're creating a lot more opportunities to just trip ourselves over with here in all of this complexity. A question on progresing the work on ire forward, can we replace the ire tables with radix trees? Or are we stuck with having both ire tables and a radix tree for some time? Darren p.s. I think the name ipftable is borderline. I understand that it is "IP forwarding table", but some might think "ipf table" and relate it to ipfilter, which it's not. Maybe call it "ip_ftable"?
_______________________________________________ networking-discuss mailing list [email protected]
