> -----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. > > 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. -Petri _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
