Simple click config is VERY slow on our system; also the PollDevice doesn't work on our tulip.

[Eddie Kohler]

OK.

> From above, it seems that the delay is caused by the background
> elements; maybe the task list got too crowded?

I think that is exactly what is happening.

Short explanation: In the kernel, FromDevice is broken into two parts:
something quick that happens at interrupt time, and a task. The
interrupt-time part enqueues the arriving packet on a queue internal to the
FromDevice (128 packets long). The task part dequeues packets from this
internal queue and pushes them through the configuration.

Normally there aren't that many tasks. However, each DelayUnqueue contains
a task. 300 DelayUnqueues == 301 tasks == FromDevice is serviced 300 times
less often == large, variable delay.

The problem here is that most of your DelayUnqueues probably aren't doing
much work. It's a shame they stay on the task list anyway.

So I've checked in something experimental that may help you. Check out
Click from anonymous CVS to get it. Basically, instead of this

 -> Queue(256)
 -> SetTimestamp 
 -> DelayUnqueue(0.00001s) 

say this:

 -> NotifierQueue(256)
 -> DelayUnqueue(0.00001s)

Now DelayUnqueue will go off the task list when it notices the
NotifierQueue is empty, and NotifierQueue will stick DelayUnqueue back on
the task list when an empty queue gets a packet. NotifierQueue acts like
Queue except for notification functionality. Use a regular Queue to get the
old behavior.

Note also no more SetTimestamp; the new DelayUnqueue does that for you,
which seems to make more sense.

Eddie