On Mon, 2008-21-07 at 08:11 +0800, Herbert Xu wrote: > This is exactly what I want to get rid of because otherwise even > if no index was specified we'll still do a hash insertion which > simply falls apart with a small hash table. Using a large hash > table on the other is bad for people who only have a few rules. True. But note: this is only during rule creation - once you create the rule (user space to kernel path), then no more hash table reference. Fast path has already a filter with actions attached, and is a mere pointer dereference. > We could do a dynamic table but so far I'm not convinced that > it's worth anybody's effort to implement :) If user<->kernel performance insertion/deletion is important, it is worth it. For example: Dave implemented dynamic hash tables on xfrm (voip setup time with ipsec is a metric used in the industry in that case) . The only operational problem i had with xfrm was lack of an upper bound of how large a table can grow; i would rather user space be told ENOMEM than continuing to grow in some cases (I actually implemented a patch which put a stop after a certain number of sad/spd - but i dont expect hugs if i was to post it;->). cheers, jamal -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
