[Click] finding pullers downstream

[Eddie Kohler]

Hi guys,

Time flies -- I assume you did StrideUnqueue, Ian.  But let's assume you 
really wanted to find-the-downstream-puller.  This would be possible using 
RouterVisitor (the new name for ElementFilter).  Here's what I would do.

(1) Check out the NotifierRouterVisitor class in lib/notifier.cc.  This is 
what NOtifier uses to find  upstream-empty/downstream-full signals, and it 
includes logic for detecting when a pull region changes to push.  (YOu don't 
want to keep searching past Unqueues.)

(2) But your visitor would not search for a NOtifier.  Instead, it would check 
for the presence of a "tickets" handler, using something like

Handler *h = e->router()->handler(e, "tickets");
if (h && h->writable()) {
     ...then this element is a relevant puller; record it and return false...
} else {
     ...check if we've switched to push more, if so stop the search by 
returning false...
}

The resulting list of elements is the list you need.  CHange their tickets by 
calling their "tickets" handlers with HandlerCall.

Eddie



Ian Rose wrote:
> 
> Cliff Frey wrote:
>> Well, sounds like you have a pretty good handle on the options.  I'll 
>> throw out two ideas though.
>>
>> Look at the ScheduleInfo element, perhaps you could use it with Unqueue 
>> elements to achieve what you want.  Alternately you could just adjust 
>> the BURST parameters on different Unqueue elements.
> 
> I did try messing about with ScheduleInfo elements but they seem to just 
> be for static initialization and don't really offer any help for 
> changing scheduling parameters at runtime.
> 
>> If what you really want is precise stride behavior, then perhaps 
>> writting a StrideUnqueue element that has N inputs and N outputs would 
>> work... this is basically combining all of your paint stuff into one 
>> element.
> 
> I like this idea (StrideUnqueue) - seems obvious in hindsight (isn't 
> that always the case).  I'll give it a try.
> 
> Thanks!
> 
> 
>> In any case, good luck!
>>
>> Cliff
>>
>> On Wed, Aug 26, 2009 at 12:08 PM, Ian Rose <ianrose at eecs.harvard.edu 
>> <mailto:ianrose at eecs.harvard.edu>> wrote:
>>
>>     Thanks for the response - see comments inline:
>>
>>
>>     Cliff Frey wrote:
>>
>>         I would look at click/lib/notifier.cc:downstream_full_signal for
>>         an example of using Router::downstream_elements(...), which
>>         could likely do what you want..
>>
>>
>>     I think I understand how to use the Router::downstream_elements()
>>     method; the problem is that I don't know how to specify the filter
>>     itself that I need to pass to it...
>>
>>
>>         However given your actual end goal, I think that you might want
>>         to do this a different way.... I would wonder if StrideSwitch
>>         <http://read.cs.ucla.edu/click/elements/strideswitch> or
>>         StrideSched <http://read.cs.ucla.edu/click/elements/stridesched>
>>         could get the job done for you instead.
>>
>>
>>     I thought about using those, but the problem with each is that they
>>     effectively mux onto (or demux out of) a single path; StrideSwitch
>>     accepts pushes from a single input and StrideSched accepts pulls
>>     from a single output.  The scenario that I am envisioning may have
>>     entirely unrelated paths.  Here is an example:
>>
>>     FromDevice(foo) -> t::Tee -> a::Queue -> Print("path 1") -> b::Discard;
>>     t[1] -> c::Queue -> Print("path 2") -> d::Discard;
>>
>>     And now I want to be able to control the relative execution rates of
>>     each of these 2 paths.  What seems most natural to me is to write to
>>     b.tickets and d.tickets, but to generalize this approach I'd like to
>>     be able to "find" b::Discard and d::Discard at runtime rather than
>>     having to pass in the element names as parameters or something
>>     kludgey like that.
>>
>>     I don't see a good way to wedge a StrideSched or StrideSwitch into
>>     this configuration to accomplish what I want.  The only way that I
>>     can see is to mark the packets so that they remember what path they
>>     came from, schedule them onto a single path, and then demux them
>>     based on the path annotation.  Here's a full example that shows what
>>     I mean:
>>
>>     InfiniteSource(DATA \<00>) -> t::Tee();
>>     t[0] -> a::Queue() -> Paint(0) -> sched::StrideSched(100, 10);
>>     t[1] -> c::Queue() -> Paint(1) -> [1]sched;
>>     sched -> Unqueue -> ps::PaintSwitch() -> cnt1::Counter() -> b::Discard;
>>     ps[1] -> cnt2::Counter() -> d::Discard;
>>
>>     Script(wait 3,
>>           write sched.tickets0 10,
>>           print "set sched.tickets0 to 10",
>>           print "");
>>
>>     Script(wait 6,
>>           write sched.tickets1 100,
>>           print "set sched.tickets1 to 100",
>>           print "");
>>
>>     Script(wait 0.5,
>>           printn "cnt1.count = ",
>>           print cnt1.count,
>>           write cnt1.reset,
>>           printn "cnt2.count = ",
>>           print cnt2.count,
>>           write cnt2.reset,
>>           print "",
>>           loop);
>>
>>     This works, but it seems a bit ugly to me what with the extra
>>     Unqueue and Paint-related elements that are required.  But hey,
>>     maybe that's the best option...
>>
>>     - Ian
>>
>>
>>
>>         Cliff
>>
>>
>>         On Wed, Aug 26, 2009 at 9:58 AM, Ian Rose
>>         <ianrose at eecs.harvard.edu <mailto:ianrose at eecs.harvard.edu>
>>         <mailto:ianrose at eecs.harvard.edu
>>         <mailto:ianrose at eecs.harvard.edu>>> wrote:
>>
>>            Hello -
>>
>>            Suppose I have a configuration something like this:
>>
>>            FromDevice(foo) -> a::Queue -> Print -> b::Discard;
>>
>>            Now, suppose that I want to write an element that, given a
>>         starting
>>            point (which would be 'a::Queue' in this case) can search
>>         downstream and
>>            find the original puller (which would be 'b::Discard' in this
>>         case).  Is
>>            this possible?  I don't think its as simple as just searching
>>         for the
>>            first downstream 'pull' element as that would return the
>>         Print element
>>            which is not what I want.
>>
>>            I'm trying to do this so that, during execution, I can write
>>         new values
>>            to b.tickets and thereby change the scheduling priorities of
>>         different
>>            paths (useless in this configuration since there is only 1
>>         path, but you
>>            get the idea).
>>
>>            Thanks!
>>            - Ian
>>            _______________________________________________
>>            click mailing list
>>            click at amsterdam.lcs.mit.edu
>>         <mailto:click at amsterdam.lcs.mit.edu>
>>         <mailto:click at amsterdam.lcs.mit.edu
>>         <mailto: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