It depends on the bare metal environment. Depending on the underlying architecture, the processing elements may have their own separate RAMs, with controlled access to common areas. This maps better to a process model with select shared memory areas than a threading model where there's implied global sharing.
On Wed, Sep 3, 2014 at 8:54 AM, Ola Liljedahl <[email protected]> wrote: > Yes but this is not a bare metal problem I think. Bare metal environments > can support multithreaded applications with shared address space? > > 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? > > > 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 > >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
