[Click] Notifier::upstream_empty_signal is always active

[Cliff Frey]

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 <ashishs.sharma at gmail.com>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
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>