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 <[email protected]> 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 >> <[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 _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
