On Thu, Jun 8, 2017 at 3:08 AM, Savolainen, Petri (Nokia - FI/Espoo) <[email protected]> wrote: > 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).
Agreed. I thought Brian's suggestion to adjust the poll rate based on the minimum resolution present for each pool made the most sense. We know from Shannon that a 10ms pool only needs to be polled every 5ms to get accurate response. Anything more frequent is waste. > > > -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
