On Wed, Sep 03, 2014 at 03:54:37PM +0200, Ola Liljedahl wrote: > Yes but this is not a bare metal problem I think. Bare metal environments > can support multithreaded applications with shared address space?
Its all depended on bare metal implementation.One possible implementation could be each core has its own address space protected with MMU and for sharing the memory and variables use common shareded memory. > > Why would you run an ODP application with multiple separate processes as > opposed to just a multithreaded process? There's so much shared state in > ODP so how much robustness does multiprocessing actually give you? Is all depended on how effective is the underlying IPC mechanism. One possible implementation could be using mmap for sharing the data and use hw scheduler to pass the message between cores. Making it as multi process will improve the stability of the system as even if a process dies in the system it can continues work on. So it an application choice. > > On 3 September 2014 15:40, Savolainen, Petri (NSN - FI/Espoo) < > [email protected]> wrote: > > > Those variables will be separate copies, if you run an ODP instance as > > multiple processes (not fork from a common ancestor). > > > > > > > > -Petri > > > > > > > > *From:* [email protected] [mailto: > > [email protected]] *On Behalf Of *ext Ola Liljedahl > > *Sent:* Wednesday, September 03, 2014 4:23 PM > > *To:* Jerin Jacob > > *Cc:* [email protected] > > *Subject:* Re: [lng-odp] ODP Bare-metal support > > > > > > > > Are you concerned that global data regions will not be mapped for all > > cores on some multicore architectures and associated runtime environments? > > Or that they will not be shared but that each core might get its own > > instance? > > > > > > > > On 3 September 2014 15:20, Ola Liljedahl <[email protected]> wrote: > > > > If you use shared data (e.g. using global variables) in a multithreaded > > environment, you will need to do explicit synchronization (barriers etc) > > from the application. > > > > I assume that the current test and example apps support multithreaded > > (including multicore) environments. Do you think there are problems with > > these apps? > > > > > > > > -- Ola > > > > > > > > > > > > > > > > On 3 September 2014 15:05, Jerin Jacob <[email protected]> > > wrote: > > > > On Wed, Sep 03, 2014 at 02:14:20PM +0400, Maxim Uvarov wrote: > > > Hello Jacob, > > > > > > that is interesting. Sound linke not huge work is needed. But in your > > case > > > you need to implement > > > separate "odp platform" which will use Cavium specific things instead of > > > linux-generic. > > > > > > I also have some notes bellow. > > > > > > On 09/03/2014 11:49 AM, Jacob, Jerin wrote: > > > >All, > > > > > > > >We have tried to add ODP bare-metal support for Cavium SoC to find the > > gap > > > >in ODP mainline API definition for bare-metal run-time environment > > support. > > > > > > > >I would like to share the findings so that we can discuss and going > > forward we can > > > >incorporate those gaps in ODP API definition and have bare metal > > support in ODP. > > > > > > > >Following are the details: > > > > > > > >1) Generic ODP API to launch the work on selected cores. > > > >Currently applications are using > > odp_linux_pthread_create/odp_linux_pthread_join > > > >API's to do the same. Which needs to changed to generic ODP API. > > > > > > > >Expectation: > > > >Function "main" in the app shall be invoked by the root core and > > > >other core shall be launched by the root core using ODP API. > > > > > > That might be good catch. We do cpu isolation for odp process in linux. > > But > > > still did not define > > > proper set up for this. Or script will isolate core and then we need odp > > app > > > moved to that specific > > > core or we do everything in odp app. In you particular case I think it's > > > reasonable to send patch > > > for this and we can discuss how is that suitable for other SoC. > > > > > > >2) ODP API's support command line parsing. > > > >If an ODP application demands for more sophisticated command line > > parsing > > > >(can not be achieved through getopt*) then I think > > > >we should have dedicated ODP API's for command line parsing like dpdk. > > > > > > Does patch "[v5] Add-global_init-paramiters" solve your problem? > > > https://patches.linaro.org/36509/ > > > > > > >3) Changes in configure.ac > > > >Need an additional configure option to skip checking the linux specific > > > >libraries in configure.ac > > > > > > That is fine. Do not see any problem with changing configure.ac or > > moving > > > it's parts > > > to platform specific folder. > > > > > > >4) Avoid using global variables in odp application for sharing > > > >the data between cores. > > > > > > Not sure that I understand that. Are you saying about reserving memory > > > blocks > > > with different names for all application instances? > > > > I was trying to say that the use of global variable for sharing the data > > between cores very > > well work on one process and multiple pthread scenario like current linux > > generic examples. > > But it would break when we move to multi process or bare metal environment. > > > > > > > > > > Best regards, > > > Maxim. > > > > > > >Any thoughts ? > > > > > > > >- Jerin. > > > >_______________________________________________ > > > >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 > > > > > > > > > > _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
