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
