On 2 May 2017 at 17:00, Bill Fischofer <bill.fischo...@linaro.org> wrote: > > > On Tue, May 2, 2017 at 3:30 AM, Maxim Uvarov <maxim.uva...@linaro.org> > wrote: >> >> I think that If vendors are going to ship several variants of schedulers >> then we need api to switch between them. If there will be only one scheduler >> then we can add getenv() variant of selection to linux-generic and test all >> of them. > > > The logical place for this sort of runtime selection is as part of an > extended parameter set to odp_init_global(). I think we're going to need > extensions to this for ODP cloud anyway, so we should discuss this next week > as part of the Sprint.
We already know the performance drops when we moved from inline to function call. Here we are using pointers to functions, loosing additional optimizations the compiler could have done. I think, a better way is to consolidate the features all these schedulers have to offer into a single scheduler with run time configurable options. > >> >> >> >> Maxim. >> >> On 2 May 2017 at 11:10, Savolainen, Petri (Nokia - FI/Espoo) >> <petri.savolai...@nokia.com> wrote: >>> >>> >>> >>> > -----Original Message----- >>> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of >>> > Honnappa Nagarahalli >>> > Sent: Tuesday, May 02, 2017 12:03 AM >>> > To: Bill Fischofer <bill.fischo...@linaro.org> >>> > Cc: lng-odp-forward <lng-odp@lists.linaro.org> >>> > Subject: Re: [lng-odp] Modular queue interface >>> > >>> > On 1 May 2017 at 12:58, Bill Fischofer <bill.fischo...@linaro.org> >>> > wrote: >>> > > >>> > > >>> > > On Sun, Apr 30, 2017 at 11:05 PM, Honnappa Nagarahalli >>> > > <honnappa.nagaraha...@linaro.org> wrote: >>> > >> >>> > >> We talked about introducing the modular queue interface. I spent >>> > >> time >>> > >> re-looking at this, according to me it does not solve any issues we >>> > >> have currently. >>> > >> >>> > >> The main issue we are trying to address currently is avoiding code >>> > >> under #ifdefs and the resulting compilation combinations and testing >>> > >> those code paths. >>> > >> >>> > >> Currently, we have 3 schedulers - default, SP and iQuery - To use >>> > >> any >>> > >> of these, ODP needs to be configured with --enable-xxx option which >>> > >> in >>> > >> turn defines the compile time #defines. The current code base has >>> > >> code >>> > >> under these flags. Modular queue interface does not change any of >>> > >> this. >>> > > >>> > > >>> > > The key is that these #ifdefs exist only within the scheduler >>> > > framework >>> > > itself (odp_schedule_if.c). The scalable scheduler should follow the >>> > same >>> > > model. >>> > >>> > Keeping #ifdefs to this file alone does not solve the CI and testing >>> > problems. We still end up having multiple code paths. >>> >>> >>> The only #ifdef used today is the built time selection of the scheduler >>> (tie callbacks to the right scheduler implementation) ... and that could be >>> done at runtime as easily. >>> >>> The big thing is that all code of all three schedulers are built in any >>> case. So, as soon as someone e.g. changes any internal interface any of >>> these schedulers use - the build breaks (no matter which scheduler was >>> selected in .configure). That does not happen when code is #ifdef'd away. >>> >>> >>> > >> I do not think there is a need to introduce a modular queue >>> > >> interface >>> > >> at this time. >>> >>> There has been always problems when modularity has been broken. Proper >>> use of internal (conversion, etc) interfaces is the way to keep (at least >>> some) sanity in the code base. One module should assume as little as >>> possible about implementation details of another module (e.g. if a handle of >>> the other module is a pointer or an index). >>> >>> -Petri >>> >> >
