On 7 September 2015 at 14:59, Savolainen, Petri (Nokia - FI/Espoo) < petri.savolai...@nokia.com> wrote:
> Scheduler timeout (wait time) enables application to wait on a schedule > call, for an finite time. Otherwise application would need to wait > infinitely (SCHED_WAIT) or poll full scheduler on full CPU speed > (SCHED_NO_WAIT). Periodic return from scheduler can be implemented also > using a timer, but it would be waste when a HW scheduler has this finite > wait time option build in. Also the “a la carte” principle fits here: user > can use the scheduler API without the timer API, if he does not really need > timers, just a way to break scheduler to from waiting for ever. > > > > Application may use this e.g. to poll some other (non-ODP) resource when > it seems that ODP side (of the application) is lightly loaded (e.g. no > single event in last 100ms). > Yes there are probably use cases for a timeout from odp_schedule. But the examples given below (e.g. timeout receiving some packet) are not valid, such cases should be handled with timers. The timeout is an event itself that should be scheduled by the scheduler so that the proper synchronisation (e.g. accessing some state associated with the queue) can be achieved. If odp_schedule() timeouts and returns without an event, the application should *not* start doing packet processing. Scheduler timeouts are for other types of application background processing and maintenance. > > -Petri > > > > > > *From:* lng-odp [mailto:lng-odp-boun...@lists.linaro.org] *On Behalf Of *ext > Ola Liljedahl > *Sent:* Monday, September 07, 2015 3:36 PM > *To:* Bill Fischofer > *Cc:* LNG ODP Mailman List > *Subject:* Re: [lng-odp] [Patch] validation: scheduler: increase time > check > > > > On 4 September 2015 at 15:36, Bill Fischofer <bill.fischo...@linaro.org> > wrote: > > That's saying that a specific worker has knowledge of what events it > should be receiving and when. The whole point of event scheduling is that > an individual worker thread is not aware of such considerations, but simply > process events that are scheduled to it. > > > > What you're describing is an application that is polling rather than > scheduling. To treat odp_schedule() as a type of poll sort of misses the > point of having an event model. > > I am with you here Bill. > > > > > > But enough digression. Sorry to sidetrack this thread. :) > > > > On Fri, Sep 4, 2015 at 8:20 AM, Nicolas Morey-Chaisemartin < > nmo...@kalray.eu> wrote: > > It could send some packet or simply handle an error case (packet should > have arrived now, something went wrong?) > > Use timers/timeouts for that. > > > > As Bill writes, an individual worker thread does not have any global > knowledge of the application state so a timeout from odp_schedule() doesn't > mean anything. > > > > > > > All this could be probably implemented by the user with timers and make > the code better, but programmers are lazy and > variable timeout is very easy to use and much lighter than creating a pool > of timers and so on... > > > > On 09/04/2015 03:13 PM, Bill Fischofer wrote: > > My point wasn't about the validation test but about the utility of the > variable timeout feature of the API itself. Can anyone really come up with > a use case where Wait for X, 2X, 3X have distinct meanings such that a > worker thread would choose one vs. another? In a portable manner? Exactly > what will the worker thread do after waiting if it returns empty handed > other than wait again? > > > > On Fri, Sep 4, 2015 at 4:56 AM, Ivan Khoronzhuk < > ivan.khoronz...@linaro.org> wrote: > > Bill, > > On 04.09.15 05:46, Bill Fischofer wrote: > > The time waiting is of dubious value (and portability) in a system with > dedicated worker threads. What else are they planning to do? Is that the > best design for the application? There are valid common uses for > ODP_SCHED_WAIT and ODP_SCHED_NO_WAIT. Everything else is questionable. > Periodic processing should be done via timers that trigger events rather > than by guesswork on the part of workers. > > > I tend to leave it as proposed Nicolas to cover existent examples. > It cannot touch cases where timers are used, I guess. > > if (ns && !cycle) > cycle = 1; > > ODP_SCHED_NO_WAIT (1) like check once, so if we passed ~ 1ns we wanted to > schedule at least once. > Currently it can lead to wait forever ODP_SCHED_WAIT (0). > > > On Thu, Sep 3, 2015 at 1:28 AM, Ivan Khoronzhuk < > ivan.khoronz...@linaro.org <mailto:ivan.khoronz...@linaro.org>> wrote: > > > > On 03.09.15 09:20, Nicolas Morey-Chaisemartin wrote: > > > > On 09/02/2015 11:16 PM, Ivan Khoronzhuk wrote: > > > > On 02.09.15 12:42, Nicolas Morey-Chaisemartin wrote: > > > On 08/26/2015 05:47 PM, Ivan Khoronzhuk wrote: > > > > On 26.08.15 18:22, Stuart Haslam wrote: > > On Wed, Aug 26, 2015 at 06:11:13PM +0300, Ivan > Khoronzhuk wrote: > > It's needed because time resolution can be a > little more than 1ns > and in this case odp_schedule_wait_time(1) > returns 0, and test > generates warn w/o reason. So increase > scheduler wait time check > from 1ns to 100ns. > > It's hard to imagine time source with > resolution more than 100ns, > so every implementation can return positive > value from > odp_schedule_wait_time(). In case if > resolution is more than 100ns > it's normal to warn about it at validation > stage, > > > The wait parameter is documented as the *minimum* > time to wait for an > event so the existing check looks OK to me. > Implementations with a lower > resolution should round up. > > > It defined as "minimum" time to wait for odp_schedule > and others, > for odp_schedule_wait_time() it's not defined as > minimum, it's simple > convert function. > > Not shure, but any of the functions I saw in > linux-generic doesn't round ticks up. > It seems that it was decided to allow application to > do it, if needed. > > But if so, we have much more to change ). > > In case if you are right, linux-generic implementation > should be corrected, > as it doesn't round it up. > > Thanks. > > I ran into this issue with our port as our clock are < > 1GHz. > So 1 ns is < 1 cycle which tends to break a few things on > the linux generic port. > > I fix this particular issue like this: > uint64_t odp_schedule_wait_time(uint64_t ns) > { > uint64_t cycle = odp_time_ns_to_cycles(ns); > if(cycle == 0) > cycle = 1; > return cycle; > } > > Not the nicest patch but it works. > The test should probably be changed to if(ns && !cycle) so > ns=0 returns 0; > > Yes. > > As said Stuart it may cause collisions with ODP_SCHED_WAIT (0) > and ODP_SCHED_NO_WAIT (1) > > I will correct it a little later. > > I don't think the collision with ODP_SCHED_NO_WAIT is too bad. We > only fall into this case if a cycle is larger than 1 ns so waiting not > waiting or waiting less thana cycle is close to the same thing. > > > Maybe you are right. > > -- > Regards, > Ivan Khoronzhuk > > _______________________________________________ > lng-odp mailing list > > lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> > https://lists.linaro.org/mailman/listinfo/lng-odp > > > -- > Regards, > Ivan Khoronzhuk > > > > > > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp > > >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
