Mike, I am finding it difficult to use this patch for my use-case where l2fwd passing "coremask" param to linux-dpdk layer. My implementation takes coremask value from "l2fwd command line argument -c" and processing of command line argument happens after odp_global_init().
odp_global_init is first api to call in any application and it does essential service init like shared mem, its lock etc.. thereafter argument processing happens so which mean passing odp_xxx_platform_init_t from odp_global_init wont really help.. What do you thin? Thanks. On 2 September 2014 02:25, Bill Fischofer <[email protected]> wrote: > Let's discuss these scenarios during tomorrow's ODP calls. Could the > various camps put together a brief summary of how they see this organized? > That would be helpful in framing the discussion. > > Thanks. > > Bill > > > On Mon, Sep 1, 2014 at 5:01 AM, Savolainen, Petri (NSN - FI/Espoo) > <[email protected]> wrote: >> >> >> >> > -----Original Message----- >> > From: ext Wiles, Roger Keith [mailto:[email protected]] >> > Sent: Monday, September 01, 2014 11:27 AM >> > To: Savolainen, Petri (NSN - FI/Espoo) >> > Cc: ext Mike Holmes; [email protected] >> > Subject: Re: [lng-odp] [PATCH v4] Add-global_init-paramiters >> > >> > >> > On Sep 1, 2014, at 3:07 AM, Savolainen, Petri (NSN - FI/Espoo) >> > <[email protected]> wrote: >> > >> > >> diff --git a/platform/linux-generic/odp_init.c b/platform/linux- >> > >> generic/odp_init.c >> > >> index 5b7e192..f595def 100644 >> > >> --- a/platform/linux-generic/odp_init.c >> > >> +++ b/platform/linux-generic/odp_init.c >> > >> @@ -8,13 +8,18 @@ >> > >> #include <odp_internal.h> >> > >> #include <odp_debug.h> >> > >> >> > >> - >> > >> -int odp_init_global(void) >> > >> +int odp_init_global(odp_global_init_t *params ODP_UNUSED, >> > >> + odp_global_platform_init_t *platform_params >> > ODP_UNUSED) >> > >> { >> > >> odp_thread_init_global(); >> > >> >> > >> odp_system_info_init(); >> > >> >> > >> + if (odp_init_platform(platform_params)) { >> > >> platform_params is used here, so remove ODP_UNUSED from argument >> > >> list. >> > > >> > >>> On the other hand, it would be better to remove odp_init_platform() >> > >>> altogether since does not do anything. It's better to add it when >> > actually used. >> > >>> The order of init calls is very important, e.g. now you could not >> > allocate shared >> > >>> memory in odp_init_platform() because it's executed before shm >> > >>> init... >> > >> odp_init_platform() does do something for DPDK / KS2 and we need a >> > place holder because >> > >> we want this to be shared between implementations don't we ? >> > >> This is the stuff that must happen before any ODP init starts to >> > satisfy the platform SDK >> > > >> > > Internals of odp_init_global() is totally platform independent - it >> > cannot be shared in general. It's HW/OS/ODP implementation dependent >> > what >> > needs to be initialized in global init, and in which order (e.g. HW >> > spinlocks before shm, shm before barriers, etc.). >> > >> > All of the platform dependent inits should be in the odp_init_platform() >> > and the calls from odp_init() should be generic for all Linux platforms. >> > The odp_init_platform() should be close to the bottom of the odp_init() >> > routine as no routine called before the platform init should require any >> > thing from the platform. >> > >> > If someone can point out why odp_init() is not generic with specific >> > examples that would help as I do not see any of the above examples as >> > being platform specific. Why would sum, spin locks and barriers (which >> > are >> > linux features) need to be in the platform. >> >> The init order depends on implementation internal dependencies. E.g. if a >> queue implementation uses pools, pools have to be initialized before queues >> (and pools cannot use queues for their implementation) - BUT if a pool >> implementation uses queues, queues have to be init before pools, etc. >> There's no point to standardize implementation internals, here or elsewhere. >> >> Although an implementation may run on Linux, e.g a spinlock may be >> implement with SW, HW queues or more specific HW... >> >> >> -Petri >> >> >> _______________________________________________ >> 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 > _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
