On Wed, Sep 03, 2014 at 11:31:40AM +0000, Savolainen, Petri (NSN - FI/Espoo) wrote: > > > > -----Original Message----- > > From: [email protected] [mailto:lng-odp- > > [email protected]] On Behalf Of ext Jacob, Jerin > > Sent: Wednesday, September 03, 2014 10:49 AM > > To: [email protected] > > Subject: [lng-odp] ODP Bare-metal support > > > > 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. > > Thread creation and launch is left to application responsibility on purpose. > E.g. there's no intention standardize OS calls that must be used to > create/pin/kill threads. That's why odp_linux.h is a helper. A linux > application can use those calls or not, it's not part of ODP. > > You could write similar helpers to launch threads (or SE cores) on Cavium HW. > > > > > 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. > > This is application dependent. Application owns the main function. Only > restriction from ODP is that odp_init_global and _local must be called, > before other ODP calls.
Tough app own the main, The invocation of the "main" function is under platform control. I was trying emphases on invocation of the function "main", where "main" should be called only once. I can think of case where "main" can be called by each core. > > > > > 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. > > Again not part of normative ODP API, but may be added as an helper. A linux > app would not use it, but maybe a SE app would. > > > 3) Changes in configure.ac > > Need an additional configure option to skip checking the linux specific > > libraries in configure.ac > > > > 4) Avoid using global variables in odp application for sharing > > the data between cores. > > Yes, good principle is to allocate all memory from odp_shm_, odp_buffer_pool, > etc. > > > > > Any thoughts ? > > Application main function may look quite different in Linux vs. SE, but it's > OK. Thread creation and other OS specifics, should be minor part of the data > plane application code base anyway. It's far more difficult to write portable > data plane application code, than main/startup code. ODP solves the hard > problem, and leaves room for different OSes and application frameworks. OK. If that's direction we want to take then I am fine with that. I was concerned about reusing odp examples on each platform with out modifying it. > > > -Petri > > > > > _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
