On 15 December 2014 at 17:04, Mike Holmes <[email protected]> wrote: > > > On 15 December 2014 at 09:56, Savolainen, Petri (NSN - FI/Espoo) > <[email protected]> wrote: >> >> >> >> > -----Original Message----- >> > From: ext Ola Liljedahl [mailto:[email protected]] >> > Sent: Monday, December 15, 2014 2:53 PM >> > To: Savolainen, Petri (NSN - FI/Espoo) >> > Cc: ext Mike Holmes; [email protected] >> > Subject: Re: [lng-odp] [PATCH 0/3] Remove odp_schedule_one for 1.0 >> > compliance >> > >> > On 15 December 2014 at 13:45, Savolainen, Petri (NSN - FI/Espoo) >> > <[email protected]> wrote: >> > > Otherwise OK, but shouldn't remove the timer example. >> > I also think it is good to have a timer example. Just shouldn't be >> > called odp_timer_test. Since we don't have any other timer example, >> > this one will have to do for now. >> > >> > > >> > > Why it's a bad example? I think we need a set of simple examples. It >> > would also demonstrate how to step out from a schedule loop (== pause -> >> > schedule until ODP_BUFFER_INVALID is returned -> tear down / step out). >> > > >> > > The new timer example could be more performance oriented, etc. >> > What is that that we want to demonstrate? >> > 1) basic timer usage (single-threaded?) >> > 2) multithreaded, combining timer and scheduler >> > 3) more? >> > >> > Can you be more specific with "more performance oriented"? >> >> I think all examples should be multi-threaded. There could be two >> categories of examples: "hello world" and more realistic/performance >> oriented. The first would demonstrate usage of an API in simplest possible >> way and with low dependency to other APIs. The simplest possible way is probably not multithreaded. Just some straight code from main, creating necessary resources (e.g. memory regions, buffer pools, queues) and then some sunny day usage of the API in question.
> > > These should be in odp/examples. I think they should be called out from the > doxygen API documentation to get the most value from them. > >> >> The second would be more complex, but would run more things in parallel >> and measure performance as well (easy / light weight check that parallel >> execution works and performs OK). These are benchmarks, not examples. As Mike writes below... Benchmarks might not be particularly simple and easy to understand. > > > These should be in odp/benchmarks, they need to allow for being too complex > to be an introductory example to a feature, but they also need to do > something useful beyond creating the configuration needed for testing unlike > anything in odp/test. If they are micro benchmarks, they shouldn't really do anything else. If they do something else, that processing will also be included in the benchmark results. > >> >> >> From current examples: >> - odp_example is type 2 for queues/scheduling. There could be another >> "hello world" queues/scheduling app. >> >> - odp_timer_test is type 1 for timers (runs 20 sec and exists). There >> could be another that runs long / forever and measures cpu load, timeout >> accuracy, etc Sounds like a benchmark to me (measuring characteristics in general, not just throughout for some specific function). This can easily become complicated. > > > I believe that the current examples are not ideal, I also feel we need to > delete test/api_test, these should be examples, benchmarks or tests. Kill them all! > >> >> >> >> -Petri >> >> > > > -- > Mike Holmes > Linaro Sr Technical Manager > LNG - ODP _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
