On Wed, Sep 03, 2014 at 11:56:01AM +0200, Ola Liljedahl wrote: > I see ODP as a HW (networking SoC) abstraction, not as an OS abstraction.
I agree. But there are services which overlaps between OS and networking SoC. We already have ODP abstractions for spin lock and shared memeory etc. > > An ODP application will not necessarily be portable between different > OS/execution environments. ODP does not limit what host functionality you > can use from your application. All my point was, Its good to have an ODP API for launching the work on different cores to avoid conditional compilation flags in the ODP application to support different execution environments. Any multi core networking SoC would need such abstraction.For example, Currently DPDK platform implementation uses "odp_linux_pthread_create" API to start work on the cores. IMO which is wrong, its not creating any linux pthread underneath. > > If you want a portable OS abstraction, this is another project with > separate API's. Feel free to start such a project. OS abstraction is a solved problem :-) Don't have much time to spend on solved problems. > > An ODP application will not necessarily be portable between different > OS/execution environments. ODP does not limit what host functionality you > can use from your application. > > If you want a portable OS abstraction, this is another project with > separate API's. Feel free to start such a project. > > Possibly there are still things where ODP could be enhanced for portability > between different environments. Even if the reference implementation is > written for Linux, we don't have to make it unportable. But it is not ODP's > responsibility to make the applications portable between different > execution environments. > > DPDK has a legacy of supporting bare metal environments in addition to > Linux user space so they had to include a lot of functionality that already > existed in Linux (and other similar OS'es). Intel could throw a thousand > people on this, LNG is more resource starved. > > > On 3 September 2014 09:49, Jacob, Jerin <[email protected]> > 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. > > > > 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. > > > > 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. > > > > 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
