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 <[email protected] > <mailto:[email protected]>> 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 > <[email protected] <mailto:[email protected]> > <mailto:[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]> > <mailto:[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
