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
