[Click] SMP Click and Timers

[Beyers Cronje]

Hi Eddie,

Thanks, that makes perfect sense. Schedule the task in the timer, and assign
the task (element) to the same thread as the pull path with
StaticThreadSched.

I'm just playing around with different configs to find the most optimum
loss-free packet receive-only rate, where latency on the pull path is of no
concern.

Do you think in theory a MT click config where one thread is dedicated to
device polling and queueing, and the second thread handles the pull path
that always ends in a Discard is the right way to go? Anyone got any
alternative approaches?

Cheers

Beyers

On 8/24/06, Eddie Kohler <kohler at cs.ucla.edu> wrote:
>
> Hi Beyers, sorry for the delay,
>
> On current Click, timers run on any CPU, so synchronization would be
> required
> here.  The simplest change that would avoid synchronization is this: Add
> another task to your SomeElement, and have the timer *schedule the task*.
>
> class SomeElement { ...
>     bool run_task();
> ...
>     Task _task;
>     Timer _timer;
> };
>
> SomeElement::SomeElement() ...
>    : _task(this), _timer(&_task)
> {
> }
>
> bool SomeElement::run_task()
> {
>     ... code that used to be in run_timer() ...
> }
>
> ...
>
> StaticThreadSched(fd 0, deq 1, the_SomeElement 1);
>
> Make sense?
>
> Alternately I could imagine allowing StaticTHreadSched to specify the CPU
> on
> which ALL timers would always run.
>
> Eddie
>
>
> Beyers Cronje wrote:
> > Hi guys,
> >
> > When using multithreaded click with StaticThreadSched can one be
> guaranteed
> > on what cpu a timer will be run?
> >
> > As a simple example, would it be required to provide synchronization for
> > element SomeElement that has a Timer that modifies mutable data inside
> > SomeElement given the following click configuration:
> >
> > fd::FromDevice(eth0) -> q::Queue;
> > q -> deq::UnQueue -> SomeElement -> Discard;
> > StaticThreadSched(fd 0, deq 1);
> >
> > Thanks
> >
> > Beyers
> > _______________________________________________
> > click mailing list
> > click at amsterdam.lcs.mit.edu
> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>