[Click] Bug ToDevice kernelmodule?

[Beyers Cronje]

Anand is right, using polling will always lead to high CPU utilization.

On 12/20/06, Anand Kanagala <akanagala at google.com> wrote:
>
> 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
> >
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>