Bill, I agree with you. But the behavior of the scheduling functions has to be specified. The current tests in odp_example() assume a fair behavior - a thread does N enqueues and gets N dequeues.
Alex On 15 October 2014 16:48, Bill Fischofer <[email protected]> wrote: > 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 > >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
