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