Right now we have a monolithic scheduler function defined for ODP. That's fine for v1.0, but I think a better way forward is to extend that to scheduling groups so that odp_schedule() is scoped over a specified queue range rather than "everything". For some implementations those queue ranges may be predefined and for others the application may define them. For now, it's better to have a single odp_schedule() call for the global range and call that sufficient for v1.0.
Bill On Wed, Oct 15, 2014 at 8:51 AM, Alexandru Badicioiu < [email protected]> wrote: > 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
