> -----Original Message-----
> From: Christophe Milard [mailto:christophe.mil...@linaro.org]
> Sent: Friday, February 03, 2017 3:37 PM
> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-
> labs.com>
> Cc: LNG ODP Mailman List <lng-odp@lists.linaro.org>
> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn to
> linux helpers
>
> On 3 February 2017 at 14:11, Savolainen, Petri (Nokia - FI/Espoo)
> <petri.savolai...@nokia-bell-labs.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Christophe Milard [mailto:christophe.mil...@linaro.org]
> >> Sent: Friday, February 03, 2017 2:29 PM
> >> To: Petri Savolainen <petri.savolai...@linaro.org>
> >> Cc: LNG ODP Mailman List <lng-odp@lists.linaro.org>
> >> Subject: Re: [lng-odp] [PATCH 1/2] helper: linux: renamed threads_extn
> to
> >> linux helpers
> >>
> >> On 3 February 2017 at 12:23, Petri Savolainen
> >> <petri.savolai...@linaro.org> wrote:
> >> > There's no platform specific helpers. Helpers may depend on
> >> > Linux and make it easier to do common series of Linux system
> >> > calls. These kind of helpers are grouped into helper/linux
> >> > directory.
> >>
> >> This is getting really confusing to me! Haven't we defined a
> >> "platform" as being a couple {OS, HW}? That is any change in this
> >> couple makes a new platform...
> >> If we hold to this definition, then linux-helpers becomes platform
> >> helpers...
> >> Now, my humble opinion is that no-one is using these linux-only
> >> helpers and no one ever will unless to enforce their usage by example
> >> that people could copy/paste: why would a programmer want to replace a
> >> well known linux system call by an ODP helper call? to save a for
> >> loop?.
> >> We are hitting the same usual problem of lack of proper definition for
> >> things, but in this special case, my proposal is called "deletion".
> >> :-)
> >>
> >> Christophe
> >
> > This is needed by OFP, for example.
> >
> > The current ODP master (after v1.13) moved things backwards as linux
> helper (which create e.g. pthreads and call odp_local_init / _term() for
> those) was renamed as "linux-generic helper". That would need OFP to
> expose "helper/linux-generic/..." in its Makefiles, which is both ugly and
> wrong (in the sense that helper code is part application code, not
> implementation code).
>
> I am really getting confused here...
> There are two sorts of things today in the helper (regarding ODPthread
> creation):
> 1)odph_odpthreads_create() familly of functions abstracts the ODP
> thread creation, i.e. will create OPD threads. Whether that is a
> pthread or linux process or anything else under the hood is hidden: It
> just creates a set of ODPthreads. (for those implementation which
> (should) supports different implemenation, a helper flag can be used
> to select what should be done)
Needed by (synthetic) validation test application that need to run on any
environment to offer API verification.
>
> 2)linux specific functions creating pthreads or processes. If the
> application uses those, the application is definitively binding itself
> to linux and is then using these functions instead of calling
> pthread_create() or fork() directely.
Most real world applications choose first an operating system and then the
thread model within that OS. Linux is the largest data plane OS (ecosystem), so
it's natural for ODP to offer helpers for that. Most real/production grade
applications would not need OS abstraction layer (option 1) above) from ODP.
>
> From Mikes comment, I understand that OFP is using functions from the
> second set. Do they have any reason for doing that? Possibly, if they
> share data allocated after the thread creatiion, not using
> odp_shm_reserve().
> If an application really binds itseft to linux, I don't see anything
> wrong if it is reflected in its Makefile ("helper/linux-generic/...").
... and
helper/odp-dpdk/
helper/odp-thunderx
helper/nxp
...
... gets ugly. A Linux application using ODP depends only on Linux and ODP
APIs, not the ODP platform under ODP API.
> If OFP does not require any specific type of ODP thread (they just
> want concurrency but don't care how this is achieved) , then they
> should be using function from the first set.
OFP slow path is Linux, not "abstract OS" (as of today at least).
>
> The Second set of function is not of much value in my eyes: They do
> not provide any kind of abstraction, but just some kind of shortcut
> avoiding a few things round fork() or pthread_create().
May be other common Linux data plane application patters will follow. Linux is
not there only for threads. Debugging, file IO, logging, ...
> When I see the confusion that they generate, compared to the little
> gain they provide (avoiding to write about 100lines of code), I still
> feel those function should be part of the application. Most programmer
> knows much more about pthread_create() and fork(), and the price
> rewritting the little piece of code will probably been seen as lower
> than learning the helper API.
>
> The role of the helpers becomes then clearer: Abstracting thing that
> can be done differentely on different platform.
Any helper code is optional. Application can copy the same lines into inside
it's code base anytime, without breaking portability. Abstract threads help our
example to run on Linux pthreads and processes without code change. Any helpers
are not rewritten between ODP implementations (platforms). ODP API is for that.
-Petri
