On Tue, Jul 14, 2015 at 05:59:53PM -0700, Tom Herbert wrote: > > Conceptually, I agree with you, but I would point out that we've had > this model of intentional collisions for a while in socket lookup. I > would assume that it's a goal to use rhashtable for socket tables, so > we'll need some solution that works with that!
Why you couldn't have them hang off a node as I described earlier? > > The other reason I wanted to have this logic outside of rhashtable > > is because for IPsec, the wildcards may in fact change after a > > "rehash". For example we may move from a /32 granularity to a > > /31 granlarity at the requst of the admin. In that case you can't > > just mix the chain from the old table with the new. > > > Where ordering elements in the table can't be sustained, scoring would > be used (e.g. scoring function can be changed on the fly, but ordering > rules can't be). I'm not sure whether we're talking about the same thing here. Let me describe the IPsec case more clearly. We have wildcards and non-wildcards. Only the non-wildcards would be hashed. The wild cards are checked outside of the hash table. The tricky bit is that the admin can flip a switch and we may either have to move previously wildcard entries that are no longer wildcards into the hash table, or move non-wildcard entries out of the table and into the wildcard list. And of course we want to do this without imposing locking on the reader :) Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
