[Click] Bug ToDevice kernelmodule?

[Anand Kanagala]

I'm you are using PollDevice, that is to be expected since it spends
the time polling instead of the linux idle loop.

-anand

On 12/20/06, Roman Chertov <rchertov at purdue.edu> wrote:
> I have noticed that Click tends to run at 99~100% capacity regardless if
> you have ToDevice or not.
>
> Roman
>
> Wim Vandenberghe wrote:
> > Hi,
> >
> > i've noticed some strange behaviour using ToDevice in kernel mode. The
> > problem was that there was a wired interface used in a ToDevice in
> > kernel mode, but there was no cable attached to the interface. At first,
> > the click module had a normal cpu load of 1%, but after half a minute or
> > so, it suddenly became 99,9%. When i performed a click-uninstall and
> > reinstalled my click config, it imediately became 99,9%
> >
> > After a while, i could pinpoint the cause of the problem. In my config,
> > now and then a packet is broadcasted on all the interfaces, including
> > the one without a wire. At first, the interface accepted the packet from
> > the todevice, probably putting it in an internal buffer. But after a
> > while, the buffer became full, and the interface signalled "busy" to the
> > todevice. This caused the todevice to continuously reschedule it's task,
> > trying to give the packet to the interface, causing the high CPU load. I
> > was able to solve the problem by changing the reschedule condition at
> > the end of the run_task methode from "bool reschedule = (busy || sent >
> > 0 || _signal.active());" to "bool reschedule = ((!busy) && (sent > 0 ||
> > _signal.active()));".
> >
> > It can be noticed that this is the same condition as when "#ifdef
> > HAVE_CLICK_KERNEL_TX_NOTIFY", but i was not able to get click working
> > with that variabele defined, that's why i changed the general reschedule
> > condition. The consequence is that the task will be rescheduled as
> > before, but only when the device is not busy.
> >
> > After this change, the run_task wasn't rescheduled anymore and the CPU
> > load remained normal. However, when a cable was plugged into the
> > interface, the run_task never was called, making the interface useless.
> > Therefore, i added a timer in the todevice, that is started if the
> > reschedule variable is false, and calling the run_task method after 500
> > ms. This way, the CPU load remains normal, but when a cable is plugged
> > into the interface, it becomes usable again.
> >
> > I don't know if this is the best way to solve the described problem, and
> > if this could be descibed as a click bug, but i thought it was best to
> > post this on the click mailing list.
> >
> > Kind regards,
> >
> > Wim
> >
> > _______________________________________________
> > click mailing list
> > click at amsterdam.lcs.mit.edu
> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>