Hi Lorenzo, There was probably a bug in the version of Click you were using. Many bugs in Unqueue "notification" (the feature that lets ToDevice go to sleep if there is nothing to send) have been fixed. ALso there must have been a Queue in between Unqueue and ToDevice, but whatever.
E [email protected] wrote: > Hi all, > > I am using click 1.6.0 as kernel module and I have encontered some issues > using an ethernet device. > In particular I have to use an unqueue element in order to stop and restart > the node transmission and I noticed that the interrupts (from > /proc/interrupts) > on the eth device are stuck and consequently the device introduces a high > latency. > This is my configuration > > |||||||||||||||||||||||||| ||||||||||||||||| > ||||||||||||||||||||| |||||||||||||||||||| > ||FromDevice|| ---> ||Queue|| ---> ||Unqueue|| ---> ... ---> ||Todevice|| > |||||||||||||||||||||||||| ||||||||||||||||| > ||||||||||||||||||||| |||||||||||||||||||| > > Is it possibile that this problem is due to an unqueue scheduling issue?? If > I stop the click thread, disable the interface (ifconfig eth0 down) > and afterwards I restart the interface and the click thread the interrupt > number restarts to grow and everyting works fine. > Is it possible that this problem could be due to the kernel which disables > the interrupts and switches to polling-mode in order to avoid the "livelock" > problem?? > I am using a kernel 2.6.19 > > I know this is a walkaround but is there a way to restart interrupts on eth > device avoiding to restart click thread? > > Thank you very much!!! > > Best regards > > Lorenzo > > _______________________________________________ > 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
