On 06/08 09:21:35, Bogdan Pricope wrote: > Brian, during yesterday meeting you mentioned about modifying this > patch to call timer processing function (_timer_run()) after fixed (or > dynamically determined) number of loops: > - If you meant application loops (calls to odp_schedule()), this is > wrong for the reasons presented in my prev. email > - If you meant scheduler internal loops (calls to do_schedule() from > inside schedule_loop()), this may work.
We are in sync. I am thinking scheduler internal loops. I implemented this yesterday as a build config (no #ifdefs !!) and the compiler will optimize out the code if _timer_run() should be called every scheduler internal loop. So, best of both worlds without any penalty if not using rate limiting by scheduler internal loops. > On 7 June 2017 at 20:02, Brian Brooks <[email protected]> wrote: > > On 06/07 17:39:16, Bogdan Pricope wrote: > >> In OFP we have this use case: N-1 cores are doing packet processing in > >> direct pktin mode; core 0 is doing odp_schedule() to process timers > >> (ARP entries expiration) and maybe other events. > >> > >> To take from this: > >> - If scheduler + timers are used, may not be use on all cores > >> - If scheduler + timers are used, odp_schedule() may not be > >> called at the rate of the packets > >> > >> > >> So, is not a good idea to condition timer processing to the number of > >> odp_schedule() calls. > > > > Can you please elaborate on how you reached this conclusion? I did not > > understand. > > > >> On 7 June 2017 at 10:30, Savolainen, Petri (Nokia - FI/Espoo) > >> <[email protected]> wrote: > >> > > >> >> > >> >> diff --git a/include/odp/api/spec/init.h b/include/odp/api/spec/init.h > >> >> index 154cdf8f..44950893 100644 > >> >> --- a/include/odp/api/spec/init.h > >> >> +++ b/include/odp/api/spec/init.h > >> >> @@ -153,6 +153,11 @@ typedef struct odp_init_t { > >> >> odp_log_func_t log_fn; > >> >> /** Replacement for the default abort fn */ > >> >> odp_abort_func_t abort_fn; > >> >> + /** Whether the application will ever call odp_schedule() or > >> >> not. > >> >> + > >> >> + Default: true > >> >> + */ > >> >> + odp_bool_t use_scheduler; > >> >> } odp_init_t; > >> > > >> > > >> > This is an API change. It should be in a separate patch and subject > >> > should be "api: init: ...". > >> > > >> > Anyway, Bill sent already a proposal that is closer what I described > >> > earlier. Init struct should have odp_feature_t bit field for feature / > >> > unused_feature selection. > >> > > >> > -Petri
