[Click] finding pullers downstream

[Ian Rose]

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>> 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>
>     https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> 
>