Eventually yes, however right now with the CUnit tests only covering "sunny day" tests that's not sufficient. odp_example at least is multi-theaded and does some limited stress testing of the APIs, which is needed.
On Mon, Dec 15, 2014 at 11:54 AM, Mike Holmes <[email protected]> wrote: > > > > On 15 December 2014 at 12:13, Bill Fischofer <[email protected]> > wrote: >> >> The odp_example() call is a very useful sanity test. >> > > That is an interesting observation that I hope goes away :) the sanity > test should now come via "make check" or we failed with the unit tests. > You should only want to look in examples to learn how to use a api that is > new to you, any other reason and you risk losing the simplicity needed to > be a lucid example. > > >> 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. >> > > Agree and if the doxygen starts to work with the examples a lot of > supporting text and even diagrams can be given. > > >> >> 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 >>> >> > > -- > *Mike Holmes* > Linaro Sr Technical Manager > LNG - ODP >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
