On Tue, May 2, 2017 at 3:30 AM, Maxim Uvarov <[email protected]> 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. > > > Maxim. > > On 2 May 2017 at 11:10, Savolainen, Petri (Nokia - FI/Espoo) < > [email protected]> wrote: > >> >> >> > -----Original Message----- >> > From: lng-odp [mailto:[email protected]] On Behalf Of >> > Honnappa Nagarahalli >> > Sent: Tuesday, May 02, 2017 12:03 AM >> > To: Bill Fischofer <[email protected]> >> > Cc: lng-odp-forward <[email protected]> >> > Subject: Re: [lng-odp] Modular queue interface >> > >> > On 1 May 2017 at 12:58, Bill Fischofer <[email protected]> >> wrote: >> > > >> > > >> > > On Sun, Apr 30, 2017 at 11:05 PM, Honnappa Nagarahalli >> > > <[email protected]> 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 >> >> >
