Major mistake odp_worker_create == odph_worker_create the "h" matters :)
On 16 April 2015 at 10:31, Mike Holmes <[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]> wrote: > >> >> >> > -----Original Message----- >> > From: ext Benoît Ganne [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] >> 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
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
