It's always a trade-off between performance (of other than timeout events) and timeout accuracy. There are variety of ODP applications, which means that it's hard to find single timer poll strategy which fit all. Optimally, polling would adapt to the timer usage.
Consider application that handles 1M packets / sec per cpu and requests timeouts with a period of 10 or 100ms. In practice, it would be enough to check the time and run timer code, only on every 1k or 10k events (packets). Especially, if time stamp read is a system call, it might not be a great idea to do that for every 1us (for every packet or every schedule() call). -Petri > -----Original Message----- > From: Bogdan Pricope [mailto:[email protected]] > Sent: Thursday, June 08, 2017 9:22 AM > To: Brian Brooks <[email protected]> > Cc: Savolainen, Petri (Nokia - FI/Espoo) <[email protected]>; > [email protected] > Subject: Re: [lng-odp] [API-NEXT v2 2/2] timer: allow timer processing to > run on worker cores > > 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. > > 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
