On Tue, Jul 14, 2015 at 09:42:49AM -0700, Tom Herbert wrote: > > Scored lookups can provides the same functionality, but requires that > we scan all the elements so I see some overhead compared to doing > ordered insertion. One way to resolve the rehash problem is search any > future table after we find a hit in the first table to see if there > are any entries that would precede the element already found. So in > the common non-rehash case lookup happens as it does now except that > we would always check for future_tbl.
There is another problem with this approach and that is it breaks the logic for determining hash collission attack. Since you're intentionally inserting multiple elements with the same hash, the chain length would be inflated. 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. 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
