Hi Tom, You need to tell Click which schedulable elements should be bound to which thread.
You have two options: Static binding - See the StaticThreadSched element http://read.cs.ucla.edu/click/elements/staticthreadsched Dynamic balanced binding - See the BalancedThreadSched element http://read.cs.ucla.edu/click/elements/balancedthreadsched Additionally, anyone that is even thinking about multithreading with Click should as a start read the "Flexible control of parallelism in a multiprocessor PC router" publication, link over at http://read.cs.ucla.edu/click/publications Lastly, I recall a recent post on the list where a recent commit on the tree broke thread scheduling, but was subsequently fixed by Eddie. So best would be to work from the most recent GIT release. Beyers On Fri, Apr 10, 2009 at 1:22 AM, Tom Gibson <[email protected]> wrote: > What would a simple click config look like to test utilizing all my > available CPU cores with simulated data? > > I tried the following, but I'm not seeing more than 1 core utilized: > > InfiniteSource(\<0800>) -> rate1 :: Counter() -> Discard; > InfiniteSource(\<0800>) -> rate2 :: Counter() -> Discard; > InfiniteSource(\<0800>) -> rate3 :: Counter() -> Discard; > InfiniteSource(\<0800>) -> rate4 :: Counter() -> Discard; > InfiniteSource(\<0800>) -> rate5 :: Counter() -> Discard; > InfiniteSource(\<0800>) -> rate6 :: Counter() -> Discard; > > > I read that a single scheduled element only ever executes on one thread. I > figured making 6 InfiniteSource elements would cause 6 cores to be > utilized. > > I configured click with --enable-multithread=8 and installed with -t 6. > What am I missing? > > -Tom > _______________________________________________ > click mailing list > [email protected] > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
