On 12/15/2014 06:04 PM, Mike Holmes wrote:
>
>
> On 15 December 2014 at 09:56, Savolainen, Petri (NSN - FI/Espoo)
> <[email protected] <mailto:[email protected]>> wrote:
>
>
>
> > -----Original Message-----
> > From: ext Ola Liljedahl [mailto:[email protected]
> <mailto:[email protected]>]
> > Sent: Monday, December 15, 2014 2:53 PM
> > To: Savolainen, Petri (NSN - FI/Espoo)
> > Cc: ext Mike Holmes; [email protected]
> <mailto:[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] <mailto:[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.
>
>
> 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 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.
I imagined a following structure:
odp
|- examples
|- tests
|- benchmarks
|- validation
--
Taras Kondratiuk
_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp
