On Mon, 2008-21-07 at 08:11 +0800, Herbert Xu wrote:

quoted text
> 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.

quoted text
> 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 netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html