[Click] Notifier::upstream_empty_signal is always active

[Eddie Kohler]

Hi, more notes;

Ashish Sharma wrote:
> The problem with simply calling the pull function is that I do not want to
> deal with the pulled packet if this queue is not valid.

A number of our elements end up having a one-packet-long internal queue to 
handle situations like this.  Check out elements/analysis/timesortedsched

> I want to have a
> simple test operation. I tried writing an extended queue element (TestQueue)
> that has a public function that tests whether the queue is empty. But here
> is what happened - when my scheduler calls
> 
> if (_signals[k] &&  (false == input(k).test_empty()))
> 
> instead of
> 
> if (_signals[k] && (p = input(k).pull()))
> 
> , the compiler complains saying error: 'const class Element::Port' has no
> member named 'test_empty' and even casting (TestQueue
> *)input(k)).test_empty() does not work.

You want "if (_signals[k] && (false == input(k).element()->test_empty()))"
I would write "if (_signals[k] && !input(k).element()->test_empty())"
You will additionally need a cast of some kind.
But I wouldn't actually want to do this at all, since it requires that your 
element be DIRECTLY hooked up to queues -- violating Click's modularity.

Creating a new notifier would be a fun and difficult project.

Eddie


> 
> So I am guessing pull and push are special click functions that can be
> invoked on a port, but other functions cannot.
> 
> I am now trying to work by creating a new notifier, although I must admit
> this is all new territory for me. Any thoughts?
> 
> Sorry for the extra long query. Don't know if this is adding to the public
> knowledge at all, but the problem is very relevant to me:)
> 
> Ashish
> 
> 
> On Fri, May 29, 2009 at 11:50 AM, Cliff Frey <cliff at meraki.com> wrote:
> 
>> 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
>>>
>>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click