[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1216607637.4847.172.camel@localhost>
Date: Sun, 20 Jul 2008 22:33:57 -0400
From: jamal <hadi@...erus.ca>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: kaber@...sh.net, davem@...emloft.net, netdev@...r.kernel.org,
johannes@...solutions.net, linux-wireless@...r.kernel.org
Subject: Re: [PATCH 20/31]: pkt_sched: Perform bulk of qdisc destruction
in RCU.
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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists