From: Benjamin LaHaise <[EMAIL PROTECTED]> Date: Thu, 9 Mar 2006 12:50:44 -0800
> Hrm, maybe use cmpxchg? That gets rid of the lock and automatically > provides us with hashed spinlocks on archs without a cmpxchg > implementation. I don't think we even need to go there, here's why. Once we have RCU in place for the TCP hash tables, we have the chance to code up dynamically sized hash tables. With the current locking, this is basically impossible, with RCU it can be done. Another thing we can do is use a secure hash via Jenkins, even though attacks on the TCP established hash table are extremely hard and require a lot of resources on the attacker's end, they are still possible and I think such protection is a reasonable thing to implement. So the game plan I'd like to propose is: 1) Ben's RCU patch 2) Changing per-chain rwlocks to spinlocks 3) RCU based dynamic TCP hash table growth 4) move to Jenkins hash with hourly or bi-hourly random number regeneration Then if things still look like they suck, we can think about doing a hashtable of spinlocks and stuff like that. I think the alternative per-chain locking schemes are good ideas, and I'm interested to see how they perform too, but I think the above should be done first. So Ben can you work to figure out what the bind(0.0.0.0) problem was? Once that is fully resolved, I think I'll apply your RCU patch to net-2.6.17. Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
