Re: [lng-odp] [PATCH 0/6] Remove Linux specifics from odp/helpers
On 14 December 2016 at 10:16, Nicolas Morey-Chaisemartin <nmo...@kalray.eu> wrote: > > > Le 12/14/2016 à 11:14 AM, Savolainen, Petri (Nokia - FI/Espoo) a écrit : > > > > From: Mike Holmes [mailto:mike.hol...@linaro.org] > > Sent: Tuesday, December 13, 2016 2:48 PM > > To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell- > labs.com> > > Cc: lng-odp@lists.linaro.org > > Subject: Re: [lng-odp] [PATCH 0/6] Remove Linux specifics from > odp/helpers > > > > > > > > On 13 December 2016 at 05:23, Savolainen, Petri (Nokia - FI/Espoo) < > petri.savolai...@nokia-bell-labs.com> wrote: > > > > > >> -Original Message- > >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of > Mike > >> Holmes > >> Sent: Monday, December 12, 2016 4:52 PM > >> To: lng-odp@lists.linaro.org > >> Subject: [lng-odp] [PATCH 0/6] Remove Linux specifics from odp/helpers > >> > >> To allow other implementations of the helpers to exist such as those > used > >> on the > >> Kalray system, we need to remove the hardwired Linux naming. This exists > >> in the > >> api, the implementation of the helper lib and the resulting library. > > Opaque thread helpers may very well exist with Linux (or Windows or > Unix) specific helpers. Majority of the applications are developed against > a defined operating system, not against an operating system abstraction > layer. For example, a linux specific helper library (consuming and > producing Linux types) would be valuable to many applications, may be even > more valuable than the opaque thread helpers used by our validation suite. > > > > I agree, but the core reason for the helper lib is to support the tests, > performance tests and examples to keep all the implementations together and > tested uniformly in the reference implimentation. > > > > Anyone can use any OS specific code they want locally, we say helpers > are not mandatory for that reason. > > > > I am fine if we have a new alternate repo or other obvious delineation > for os specific help. However putting them in the main helper API makes > portability impossible and we want to promote that first and allow for all > performance optimizations to be done locally if needed. We do know that we > have at least two OS'es actively using ODP. > > > > HTML stops here > > > > The point is that with Linux and ODP an application is directly portable > to 90-95% of all networking SoCs. Also if an SoCs does not support Linux > it's typically because of lacking HW features such as MMU, which again may > restrict me to use it in the first place. So, typically 100% on the SoCs > I'm interested in do support Linux and thus I do not need an opaque OS > helper but a Linux helper. > > > > > > -Petri > > > > I don't mind the helper library to have OS specific code in it. As long as: > - Source and hear file are separated so the helper lib can be compiled on > another OS by removing the linux specific file from the Makefile.am > - The associated tests can be disabled > - The ODP test suite (at least the common_plat) part does not use any of > them. > > Nicolas > I plan to move the linux specific helper APIs to their own sub dir, the current helpers will be the agnostic ones that all of the reference examples and tests use. This will gain support for BSD etc at some point under the application transparent api. The OS specific extension helpers can live in the repo, they will have their own life with possibly more OS specific support but not be portable across OS. I will look at compile flags to include them, and probably move the src so it is obvious they are non portable extensions. -- Mike Holmes Program Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs "Work should be fun and collaborative, the rest follows"
Re: [lng-odp] [PATCH 0/6] Remove Linux specifics from odp/helpers
Le 12/14/2016 à 11:14 AM, Savolainen, Petri (Nokia - FI/Espoo) a écrit : > > From: Mike Holmes [mailto:mike.hol...@linaro.org] > Sent: Tuesday, December 13, 2016 2:48 PM > To: Savolainen, Petri (Nokia - FI/Espoo) > <petri.savolai...@nokia-bell-labs.com> > Cc: lng-odp@lists.linaro.org > Subject: Re: [lng-odp] [PATCH 0/6] Remove Linux specifics from odp/helpers > > > > On 13 December 2016 at 05:23, Savolainen, Petri (Nokia - FI/Espoo) > <petri.savolai...@nokia-bell-labs.com> wrote: > > >> -Original Message- >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Mike >> Holmes >> Sent: Monday, December 12, 2016 4:52 PM >> To: lng-odp@lists.linaro.org >> Subject: [lng-odp] [PATCH 0/6] Remove Linux specifics from odp/helpers >> >> To allow other implementations of the helpers to exist such as those used >> on the >> Kalray system, we need to remove the hardwired Linux naming. This exists >> in the >> api, the implementation of the helper lib and the resulting library. > Opaque thread helpers may very well exist with Linux (or Windows or Unix) > specific helpers. Majority of the applications are developed against a > defined operating system, not against an operating system abstraction layer. > For example, a linux specific helper library (consuming and producing Linux > types) would be valuable to many applications, may be even more valuable than > the opaque thread helpers used by our validation suite. > > I agree, but the core reason for the helper lib is to support the tests, > performance tests and examples to keep all the implementations together and > tested uniformly in the reference implimentation. > > Anyone can use any OS specific code they want locally, we say helpers are not > mandatory for that reason. > > I am fine if we have a new alternate repo or other obvious delineation for os > specific help. However putting them in the main helper API makes portability > impossible and we want to promote that first and allow for all performance > optimizations to be done locally if needed. We do know that we have at least > two OS'es actively using ODP. > > HTML stops here > > The point is that with Linux and ODP an application is directly portable to > 90-95% of all networking SoCs. Also if an SoCs does not support Linux it's > typically because of lacking HW features such as MMU, which again may > restrict me to use it in the first place. So, typically 100% on the SoCs I'm > interested in do support Linux and thus I do not need an opaque OS helper but > a Linux helper. > > > -Petri > I don't mind the helper library to have OS specific code in it. As long as: - Source and hear file are separated so the helper lib can be compiled on another OS by removing the linux specific file from the Makefile.am - The associated tests can be disabled - The ODP test suite (at least the common_plat) part does not use any of them. Nicolas
Re: [lng-odp] [PATCH 0/6] Remove Linux specifics from odp/helpers
From: Mike Holmes [mailto:mike.hol...@linaro.org] Sent: Tuesday, December 13, 2016 2:48 PM To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia-bell-labs.com> Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] [PATCH 0/6] Remove Linux specifics from odp/helpers On 13 December 2016 at 05:23, Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia-bell-labs.com> wrote: > -Original Message- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Mike > Holmes > Sent: Monday, December 12, 2016 4:52 PM > To: lng-odp@lists.linaro.org > Subject: [lng-odp] [PATCH 0/6] Remove Linux specifics from odp/helpers > > To allow other implementations of the helpers to exist such as those used > on the > Kalray system, we need to remove the hardwired Linux naming. This exists > in the > api, the implementation of the helper lib and the resulting library. Opaque thread helpers may very well exist with Linux (or Windows or Unix) specific helpers. Majority of the applications are developed against a defined operating system, not against an operating system abstraction layer. For example, a linux specific helper library (consuming and producing Linux types) would be valuable to many applications, may be even more valuable than the opaque thread helpers used by our validation suite. I agree, but the core reason for the helper lib is to support the tests, performance tests and examples to keep all the implementations together and tested uniformly in the reference implimentation. Anyone can use any OS specific code they want locally, we say helpers are not mandatory for that reason. I am fine if we have a new alternate repo or other obvious delineation for os specific help. However putting them in the main helper API makes portability impossible and we want to promote that first and allow for all performance optimizations to be done locally if needed. We do know that we have at least two OS'es actively using ODP. HTML stops here The point is that with Linux and ODP an application is directly portable to 90-95% of all networking SoCs. Also if an SoCs does not support Linux it's typically because of lacking HW features such as MMU, which again may restrict me to use it in the first place. So, typically 100% on the SoCs I'm interested in do support Linux and thus I do not need an opaque OS helper but a Linux helper. -Petri
Re: [lng-odp] [PATCH 0/6] Remove Linux specifics from odp/helpers
On 13 December 2016 at 05:23, Savolainen, Petri (Nokia - FI/Espoo) wrote: > > > > -Original Message- > > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of > Mike > > Holmes > > Sent: Monday, December 12, 2016 4:52 PM > > To: lng-odp@lists.linaro.org > > Subject: [lng-odp] [PATCH 0/6] Remove Linux specifics from odp/helpers > > > > To allow other implementations of the helpers to exist such as those used > > on the > > Kalray system, we need to remove the hardwired Linux naming. This exists > > in the > > api, the implementation of the helper lib and the resulting library. > > Opaque thread helpers may very well exist with Linux (or Windows or Unix) > specific helpers. Majority of the applications are developed against a > defined operating system, not against an operating system abstraction > layer. For example, a linux specific helper library (consuming and > producing Linux types) would be valuable to many applications, may be even > more valuable than the opaque thread helpers used by our validation suite. > I agree, but the core reason for the helper lib is to support the tests, performance tests and examples to keep all the implementations together and tested uniformly in the reference implimentation. Anyone can use any OS specific code they want locally, we say helpers are not mandatory for that reason. I am fine if we have a new alternate repo or other obvious delineation for os specific help. However putting them in the main helper API makes portability impossible and we want to promote that first and allow for all performance optimizations to be done locally if needed. We do know that we have at least two OS'es actively using ODP. > > > -Petri > > -- Mike Holmes Program Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs "Work should be fun and collaborative, the rest follows"
Re: [lng-odp] [PATCH 0/6] Remove Linux specifics from odp/helpers
> -Original Message- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Mike > Holmes > Sent: Monday, December 12, 2016 4:52 PM > To: lng-odp@lists.linaro.org > Subject: [lng-odp] [PATCH 0/6] Remove Linux specifics from odp/helpers > > To allow other implementations of the helpers to exist such as those used > on the > Kalray system, we need to remove the hardwired Linux naming. This exists > in the > api, the implementation of the helper lib and the resulting library. Opaque thread helpers may very well exist with Linux (or Windows or Unix) specific helpers. Majority of the applications are developed against a defined operating system, not against an operating system abstraction layer. For example, a linux specific helper library (consuming and producing Linux types) would be valuable to many applications, may be even more valuable than the opaque thread helpers used by our validation suite. -Petri
[lng-odp] [PATCH 0/6] Remove Linux specifics from odp/helpers
To allow other implementations of the helpers to exist such as those used on the
Kalray system, we need to remove the hardwired Linux naming. This exists in the
api, the implementation of the helper lib and the resulting library.
Whit this in place we are closer to an ABI compatible helper library. A follow
on patch will address the static inline problems.
Mike Holmes (6):
helper: rename linux.h to threads.h
helper: remove unused linux specific apis
helper: move thread to os/linux directory
helper: select os in configure
helper: rename libodphelper to remove -linux
helper: take default os from odp platform
configure.ac | 16 +-
example/Makefile.inc | 2 +-
example/classifier/odp_classifier.c| 2 +-
example/generator/odp_generator.c | 2 +-
example/ipsec/odp_ipsec.c | 2 +-
example/l2fwd_simple/odp_l2fwd_simple.c| 2 +-
example/l3fwd/odp_l3fwd.c | 2 +-
example/packet/odp_pktio.c | 2 +-
example/switch/odp_switch.c| 2 +-
example/time/time_global_test.c| 2 +-
example/timer/odp_timer_test.c | 2 +-
helper/Makefile.am | 10 +-
helper/include/odp/helper/{linux.h => threads.h} | 83 +---
helper/{linux.c => os/linux/thread.c} | 218 +
helper/test/Makefile.am| 8 +-
helper/test/odpthreads.c | 2 +-
helper/test/process.c | 92 -
helper/test/thread.c | 87
...libodphelper-linux.pc.in => libodphelper.pc.in} | 4 +-
platform/linux-generic/m4/configure.m4 | 2 +
test/Makefile.inc | 2 +-
test/common_plat/common/odp_cunit_common.c | 2 +-
.../common_plat/miscellaneous/odp_api_from_cpp.cpp | 2 +-
test/common_plat/performance/odp_crypto.c | 2 +-
test/common_plat/performance/odp_l2fwd.c | 2 +-
test/common_plat/performance/odp_pktio_perf.c | 2 +-
test/common_plat/performance/odp_sched_latency.c | 2 +-
test/common_plat/performance/odp_scheduling.c | 2 +-
test/common_plat/validation/api/Makefile.inc | 2 +-
test/common_plat/validation/api/timer/timer.c | 2 +-
test/linux-generic/Makefile.inc| 2 +-
test/linux-generic/mmap_vlan_ins/mmap_vlan_ins.c | 2 +-
test/linux-generic/pktio_ipc/ipc_common.h | 2 +-
test/linux-generic/ring/ring_stress.c | 2 +-
34 files changed, 55 insertions(+), 515 deletions(-)
rename helper/include/odp/helper/{linux.h => threads.h} (74%)
rename helper/{linux.c => os/linux/thread.c} (70%)
delete mode 100644 helper/test/process.c
delete mode 100644 helper/test/thread.c
rename pkgconfig/{libodphelper-linux.pc.in => libodphelper.pc.in} (77%)
--
2.9.3
