The odp_example() call is a very useful sanity test. The problem with many of the others is that they are not self-contained and assume some sort of (unspecified) I/O configuration and source/sink.
On Mon, Dec 15, 2014 at 11:06 AM, Ola Liljedahl <[email protected]> wrote: > > 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 >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
