On Tue, Jul 14, 2015 at 2:57 AM, Herbert Xu <herb...@gondor.apana.org.au> wrote: > Tom Herbert <t...@herbertland.com> wrote: >> The obj_orderfn function may be specified in the parameters for a >> rhashtable. When inserting an element this function is used to order >> objects in a bucket list (greatest to least ordering value).This >> allows entries to have wild card fields, where entries with >> more specific information match are placed first in the bucket. >> When a lookup is done, the first match found will contain >> the most specific match. >> >> Signed-off-by: Tom Herbert <t...@herbertland.com> > Hi Herbert,
> I think this is fundamentally broken with respect to rehashing. > During a rehash you're going to have some elements in the old table > and some in the new table. At which point all your ordering > guarantees go out of the window. > Yes, good observation. > I actually need something quite similar for IPsec. What I was > planning on doing is have the actual objects hang off an ordered > list object. The ordered list would then be the thing that you > insert into rhashtable. This means that during rehashing they > get moved atomically. > Hmm, I do like the simplicity of a flat linear search. 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. 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
