Hi Ashish, First off, I am very suspicious that the performance here is actually the issue. Assuming you have queues hooked up directly to this element, calling pull() and having it return NULL should just be a very simple/fast function call. So really I think that you are talking about changing from a function call to an indirect pointer read or something.
Or does it really bother you that click is using 100% of the CPU even though it isn't getting anything done? This rarely matters, but I guess if you are using the machine for other things as well, or are power-constrained. In any case, if you are actually that performance sensitive, then you could either build one element that contained all of the queues, or you could keep a Vector of Queue objects that are upstream, and just directly look at their sizes rather than calling pull()... but I doubt that it would be any faster. If you are just bothered by the CPU utilization (this will not likely make any performance difference, or might slow things down slightly, but can still be nice if you are on a shared system), then you need to have a notifier in your element, and override the cast() function to look for Notifier::EMPTY_NOTIFIER (like notifierqueue.cc) and correctly keep that notifier in the right state. Cliff On Fri, May 29, 2009 at 2:05 AM, Ashish Sharma <[email protected]>wrote: > Hi all, > I am trying to write a modified scheduler (based on prioscheduler). The new > scheduler maintains a list of permissible queues from which the scheduler > can draw packets from. So if there are n input queues to the scheduler, at > any point of time only a subset of the queues are "valid" and the scheduler > must check only these queues to see if they have any packets to transmit. > This subset of "valid" queues changes with time. > > I am relying on the Notifier::upstream_empty_signal to check if the input > queues are non-empty. But, it turns out that the signal is active most of > the time and is only reset after the pull function is called which returns > null in case of an empty queue. Since the valid/invalid test is an > expensive > one, what I would like is for the Notifier signal to act like a test > function, so I only perform the valid/invalid operation if a queue is > non-empty. Further, in case the queue is not empty but belongs to the set > of > "invalid" queues, I do not want to put the packet back at the head of the > queue (of which I cannot think of a simple way of doing from within the > scheduler element). > > One solution is that I extend the Queue element to include a test function > and along with the signal check the test function. > > Is there a clean way to make the Notifier signal active only when the input > queue is really non-empty and not a false alarm? > > Thank you for your time. I would really appreciate any suggestions or > thoughts. > > Thanks > Ashish > _______________________________________________ > 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
