On 15 October 2014 14:52, Alexandru Badicioiu < [email protected]> wrote:
> 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. > Another reason for this behavior to be specified separately (some kind of global configuration?) and not every time the application makes a schedule call. > 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. > Push and pull start to have a lot of meanings. It is good that you define them in this context. I would call both of these "pull mode". The scheduler does not run ahead an unlimited amount of frames and pushes frames to different cores (that would be the classifier's job). The scheduler is allowed to schedule ahead of the application in order to decrease schedule latency and allow cache prefetching. The amount of prescheduling (as a hint, not a strict requirement) should be configurable so that the application would be able to select the trade-off which makes most sense for it. > Also the term "global scheduling" is confusing and may not reflect the > reality of the HW. > What does global scheduling mean? All scheduled queues belong to the same scheduling group? -- Ola > > 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
