Petri Savolainen(psavol) replied on github web page:

line 7
@@ -53,9 +53,6 @@ env:
         - CONF=""
         - CONF="--disable-abi-compat"
         - CONF="--enable-deprecated"
-        - CONF="--enable-schedule-sp"
-        - CONF="--enable-schedule-iquery"
-        - CONF="--enable-schedule-scalable"
         - CONF="--enable-dpdk-zero-copy"

There can be just one config option: --with-scheduler=foo. When that's defined 
then "foo" would be used (fixed at build time). If --with-scheduler is not 
found, the value of ODP_SCHEDULER=foo environment variable is used (run time 
selection is the default behavior). If the variable is not found then the 
default scheduler is used.

> Dmitry Eremin-Solenikov(lumag) wrote:
> This would mean that we have now 4 options to test, instead of just one. What 
> about renaming 'default' scheduler to some sensible name and adding 
> `--with-scheduler-default=FOO`? Then we will have just one combination to 
> test.

>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>> Perhaps `--enable-schedule-dynamic` (default) to indicate run time selection 
>> that can be overridden by a specific static selection at `./configure` time 
>> via the other `--enable-schedule-xxx` options?

>>> Petri Savolainen(psavol) wrote:
>>> Run time selection is good addition and can be even the default behavior. 
>>> Anyway, I'd like to keep the build time selection also, since usually one 
>>> application uses the same scheduler always. Fixing the scheduler at build 
>>> time avoids accidentally usage of different schedulers in different servers 
>>> (or VMs or test environments) and thus avoid problems/debugging caused by 
>>> that.
updated_at 2018-02-13 07:52:10

Reply via email to