[Click] finding pullers downstream

[Cliff Frey]

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.

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.

In any case, good luck!

Cliff

On Wed, Aug 26, 2009 at 12:08 PM, Ian Rose <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>> 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
>>
>>
>>