I expect that we cannot modify every current and future example app to be OS agnostic (== bare metal ready). Some examples, like IPsec, depend on third party libraries, which in turn may depend on other Linux/Posix interfaces. Third party code may expect either process or pthread model. It’s good to demonstrate explicitly how ODP is setup in both of those cases. Majority of the applications will run Linux anyway.
I recommend that we support OS agnostic validation suite (triple the testing effort there) - but examples/other test apps can choose which from the three models (OS agnostic, Linux process or pthread) suite them the best. So, all three helper APIs are needed. -Petri From: ext Mike Holmes [mailto:[email protected]] Sent: Friday, April 17, 2015 4:04 PM To: Savolainen, Petri (Nokia - FI/Espoo) Cc: ext Benoît Ganne; Taras Kondratiuk; lng-odp Subject: Re: [lng-odp] [PATCH] api_test: remove odp_shm_test On 17 April 2015 at 03:22, Savolainen, Petri (Nokia - FI/Espoo) <[email protected]<mailto:[email protected]>> wrote: It’s a good idea to add odph_worker, but that would be added in parallel to odph_linux. This raises a question in my mind, if we only need to support the tests and examples we provide and can test, why would we have that parallel linux specific api in our code base - we wont be using it at all. So that applications which explicitly need to create Linux processes, pthreads or both can still do that. Who's application ? anyone is free to do that if needed that is why they are helpers and not part of the API, but why do we add support if we wont be using it. It will be like rings, in the code base and never used with its test rotten and core dumping. All validation tests can use odp_worker (only), but e.g. some examples/apps may need direct access to Linux process/thread data structs. We dont have any to date and if we do get to this situation in linux-generic I start to question if we are heading away from the core of ODP being agnostic to OS etc and so should we do that ? I do see us running odph_worker in both of the linux modes in the validation of linux generic so that we test odp_worker as a process and thread under Linux. Agree that test/api_test and helper/ring should be removed. -Petri From: ext Mike Holmes [mailto:[email protected]<mailto:[email protected]>] Sent: Thursday, April 16, 2015 5:34 PM To: Savolainen, Petri (Nokia - FI/Espoo) Cc: ext Benoît Ganne; Taras Kondratiuk; lng-odp Subject: Re: [lng-odp] [PATCH] api_test: remove odp_shm_test Major mistake odp_worker_create == odph_worker_create the "h" matters :) On 16 April 2015 at 10:31, Mike Holmes <[email protected]<mailto:[email protected]>> wrote: Before this valuable thread hijacks the patch can some one review it ? I dont think there is any good reason to keep odp_shm. I have been working with Christophe and a really clean solution is emerging that untangles a lot of this. So to state my vision in rough form * helper implementation is under helpers not in Linux generic, it is os dependent not platform dependent. * test/api_test is deleted * helpers do have tests in the appropriate place in the structure if they are functional in any way. * A helper that supports creating an odp_worker that is OS independent at the API level is needed. It will have a Linux implementation equal to what we have now. We need this to make tests and examples a little more portable. We will not provide support for bare metal etc so this is an API change only at heart. The choice between process or thread for the linux odp_worker create will be at compile time. We dont use the process model in the validation tests currently anyway. * We delete rings unless some one has a use case to keep them. * We need to account for OS and platform specific configuration that is needed for the tests to run - Christophe now have a very elegant patch brewing. It makes the pktio_run etc much cleaner and make the tests a truly independent library potentially, with no hacks to get platform specifics solved to run them. * Helpers like the protocol headers are clearly used by implementations and applications this should be allowed, but helpers should be separated where they only support apps, examples and tests, thus creating odp_workers is a different kind of helper. * ODP != OS independence but tests need to be closer to that than we have now unless we downplay the validation suite. I think with an OS independent odp_wroker_create + Christophes work we will hit the sweet spot avoiding the hard work for non linux cases, but leaving the door open for bare-metal folks to do what they need to. Would love to have this discussion in next Tuesdays public call if we dont beat it ti death before then. On 16 April 2015 at 07:16, Savolainen, Petri (Nokia - FI/Espoo) <[email protected]<mailto:[email protected]>> wrote: > -----Original Message----- > From: ext Benoît Ganne [mailto:[email protected]<mailto:[email protected]>] > Sent: Thursday, April 16, 2015 1:51 PM > To: Savolainen, Petri (Nokia - FI/Espoo); Taras Kondratiuk > Cc: lng-odp > Subject: Re: [lng-odp] [PATCH] api_test: remove odp_shm_test > > >> I think there is a grey area here: we say helpers are not part of ODP, > >> but we cannot compile ODP tests and examples w/o them. Can we really > >> consider an implementation to be ODP-compliant w/o those? > > > An implementation does not have to (should not) re-implement the > > odp/helper directory. It can be delivered as is (similar to odp/test > > or odp/example). Helpers can be thought as part of the test suite > > infrastructure, but pulled to the top level as definitions are > > generic enough. > > For example, tests and examples make heavy use of odph_linux_pthread_* . > This is a problem for eg. bare metal environment. I believe that Phil > proposed during the call to rename that "execution_unit" or something > similar exactly for this reason. > But then we also have the problem with odph_linux_process_*, especially > for our platform where we could have different images for different > process: some for Linux, some for bare metal. Bare metal images cannot > run under Linux and vice-versa. > If helpers are needed for examples and tests, I would argue they should > be as platform-neutral as possible and carefully defined. This is not a > problem for protocols headers, but it is for processes management. > > ben Some tests/examples (e.g. Ipsec) include also Linux/posix headers directly (so bare metal problems are not limited to odph_linux_*). And that's OK - we don't want ODP to become another OS. The software written under the ODP project may not be able support different bare metal targets, but leave that (validation) effort to individual vendors. In practice, test suite/examples depend on Linux now, and that may be the case in the future also (as conclusion of this discussion). The important thing is that the API does not depend on Linux/POSIX/etc - only on C99. -Petri _______________________________________________ lng-odp mailing list [email protected]<mailto:[email protected]> https://lists.linaro.org/mailman/listinfo/lng-odp -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org<http://www.linaro.org/> │ Open source software for ARM SoCs -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org<http://www.linaro.org/> │ Open source software for ARM SoCs -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org<http://www.linaro.org/> │ Open source software for ARM SoCs
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
