On Tue, Jul 14, 2015 at 4:58 PM, Herbert Xu <herb...@gondor.apana.org.au> wrote: > 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. > 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!
> 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). Tom > 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
