[Click] finding pullers downstream

[Ian Rose]

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
> 
> 
>