How scheduling is done is implementation-defined. Trying to specify that at the API level will severely limit portability since SoCs that implement HW scheduling differ in how this is done.
On Wed, Oct 15, 2014 at 8:43 AM, Ola Liljedahl <[email protected]> wrote: > I guess prescheduling (the mode selected by odp_schedule()) is a bit > dangerous if the application thread is not scheduling and processing events > all the time. Prescheduled events will have to wait until the application > thread comes back and requests another event, this could add a lot of > latency to prescheduled events and all other events from the same queue(s) > (if ordered or atomic). > > Couldn't this scheduling behavior be specified when you create a scheduled > queue? At least during the initialization phase so that the ODP > implementation would have a better chance of configuring the HW > appropriately. Not all implementations will be able to switch between > schedule() and schedule_one() behaviors on a per-call basis. Even if it > seems useful to be able to change scheduling behavior on the fly, it might > not be possible and the actual scheduling behavior is more or less > implementation-specific. The minimum is to remove the word "guaranteed" and > just state that this is a hint from the application to the implementation. > > -- Ola > > On 15 October 2014 15:13, Savolainen, Petri (NSN - FI/Espoo) < > [email protected]> wrote: > >> Hi, >> >> It’s not only push vs pull. It can be also “pull many” vs “pull one”. >> Alex, I think your HW supports both: pull many or pull only one. >> >> Global scheduling == SoC level scheduling, not scheduling from e.g. per >> core level stash of (pre-scheduled) buffers/queues. >> >> The first goal of the function is to streamline application main loop >> when application have to step out of the schedule loop often (e.g. in >> addition to ODP scheduler, poll a third party lib). So instead of ... >> >> main_odp_loop >> { >> odp_schedule_resume() >> >> buf = odp_schedule(...) >> >> <process it> >> >> odp_schedule_pause() >> >> while ( (buf = odp_schedule(...)) != INVALID) >> { >> <process it> >> } >> >> odp_schedule_release_atomic() >> >> return >> } >> >> ... you can do ... >> >> main_odp_loop >> { >> >> buf = odp_schedule_one(...) >> >> <process it> >> >> odp_schedule_release_atomic() >> >> return >> } >> >> >> The second goal is to optimize for QoS response time. It could be handled >> with another call that tells ODP to optimize for QoS instead of throughput. >> >> >> -Petri >> >> >> From: [email protected] [mailto: >> [email protected]] On Behalf Of ext Alexandru Badicioiu >> Sent: Wednesday, October 15, 2014 3:52 PM >> To: Ola Liljedahl >> Cc: [email protected] >> Subject: Re: [lng-odp] odp_schedule() vs. odp_schedule_one() >> >> The documentation suggests that these two calls can be used in the same >> application which may be a problem also for platforms which do support both >> modes, but not at the same time or without re-initialization, >> re-configuration, etc. By modes I mean PUSH (odp_schedule()), when the >> scheduler runs independently of the application and pushes frames to the >> application, and PULL (odp_schedule_one()) when the scheduler runs when >> the application decides and the application pulls the frames from the >> scheduler. >> Also the term "global scheduling" is confusing and may not reflect the >> reality of the HW. >> >> >> Alex >> >> On 15 October 2014 15:15, Ola Liljedahl <[email protected]> wrote: >> * Schedule one buffer >> * >> * Like odp_schedule(), but is quaranteed to schedule only one buffer at >> a time. >> * Each call will perform global scheduling and will reserve one buffer >> per >> * thread in maximum. When called after other schedule functions, returns >> * locally stored buffers (if any) first, and then continues in the global >> * scheduling mode. >> * >> * This function optimises priority scheduling (over throughput). >> >> As Taras commented, some implementations will not be able to truly >> schedule only one event at a time. Scheduler implementations could use a >> pipelined designed where events are scheduled in advance so that the next >> event can be prefetched while the current event is being processed. This >> will limit concurrent processing (e.g. an idle core could have received >> that second event and process it concurrently, this would have reduced >> latency for that event). >> >> odp_schedule_one() has the same functionality as odp_schedule(). However >> it is supposed to guarantee only one event at a time is scheduled in order >> to prioritize latency to the potential detriment of throughput. >> >> We question whether odp_schedule_one() actually has to guarantee only one >> event at a time. The functionality provided is the same for these two >> calls. One call is focused on throughput (and minimizing overhead, e.g.by >> allowing prescheduling and do prefetching), the other is focused on latency >> (at the cost of overhead). An ODP implementation could use the same >> implementation for both functions (some ODP implementations will always >> schedule events in advance, other implementations will always only schedule >> one event at a time). odp_schedule_one() just hints the ODP implementations >> that latency and concurrent processing is more important but this is not a >> strict requirement. >> >> Maybe we only need one schedule call and possibly use a different >> mechanism to hint the ODP scheduler whether to optimize for throughput >> (e.g. preschedule/prefetch) or latency. >> >> --Ola >> >> >> _______________________________________________ >> lng-odp mailing list >> [email protected] >> http://lists.linaro.org/mailman/listinfo/lng-odp >> >> > > _______________________________________________ > lng-odp mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/lng-odp > >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
