On 5 September 2014 03:16, Mike Holmes <[email protected]> wrote: > Yes, but that may be my ignorance :) I don't know why the old way is needed > now.
Thats may be because I was confused and getting impression that expectation to do two level of argument processing although sounds stupid so thats why wanted to be loud and clear. I could send param specific dpdk-l2fwd patch to list now. Thanks for clarification. > > > On 4 September 2014 17:44, Santosh Shukla <[email protected]> wrote: >> >> On 5 September 2014 03:08, Mike Holmes <[email protected]> wrote: >> > >> > >> > >> > On 4 September 2014 17:30, Santosh Shukla <[email protected]> >> > wrote: >> >> >> >> On 5 September 2014 00:13, Mike Holmes <[email protected]> wrote: >> >> > I am confused about the init sequence, I imagine this >> >> > >> >> > >> >> > >> >> > >> >> > On 4 September 2014 04:40, Santosh Shukla <[email protected]> >> >> > wrote: >> >> >> >> >> >> On 4 September 2014 13:40, Savolainen, Petri (NSN - FI/Espoo) >> >> >> <[email protected]> wrote: >> >> >> >> Conti.. >> >> >> >> >> >> >> >> Root cause of my concern is not entirely specific to this patch. >> >> >> >> Its >> >> >> >> more related to odp api initialization calling sequence in >> >> >> >> application. From early days, we used to follow below step in >> >> >> >> application - >> >> >> >> >> >> >> >> odp_global_init() -> which does almost everything for platform >> >> >> >> initialization. >> >> >> >> odp_shm_reserve() -> used for argument processing then >> >> >> >> odp_create_thread etc... >> >> >> >> >> >> >> >> Now we found a need to introduce platform specific init hints, >> >> >> >> coming >> >> >> >> from application. Therefore order of odp_xxx_init api calling >> >> >> >> sequence >> >> >> >> should change too. >> >> >> >> >> >> >> >> >> >> >> >> Something like. >> >> >> >> >> >> >> >> Application "X" >> >> >> >> >> >> >> >> main () >> >> >> >> { >> >> >> >> >> >> >> >> - First do argument processing. For that, call odp_shm_init() in >> >> >> >> application and remove it from odp_global_init OR application has >> >> >> >> to >> >> >> >> allocate memory(bad idea ... I guess). >> >> >> > >> >> >> > argX and argY can be allocated from stack or heap (malloc). Shared >> >> >> > memory is not needed for those to be able to call >> >> >> > odp_global_init(). >> >> >> > ODP >> >> >> > will take copy of the argument, argX/Y can be destroyed after the >> >> >> > call. >> >> >> >> >> >> Not to *call odp_global_init* , It is to pass command line processed >> >> >> input to odp_globa_init().. Are you suggesting calling of >> >> >> parse_args() >> >> >> before and after odp_global_init()? >> >> >> >> >> >> >> >> >> > >> >> >> > After ODP init, you can allocate shm and copy args there if you >> >> >> > need >> >> >> > to >> >> >> > share those within your app. >> >> >> >> >> >> Same argument processed twice ? isn't it. >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > -Petri >> >> >> > >> >> >> >> >> >> >> >> - Then call odp_global/platform_init(argX, argY); where arg -X : >> >> >> >> global param, Y : platform centric stuff. >> >> >> >> >> >> >> >> ... Rest stuff as it is. >> >> >> >> } >> >> >> >> >> >> >> >> >> >> >> >> Any idea? thoughts? Does above make sense. Thanks. >> >> >> >> >> >> >> >> >> >> > >> >> > >> >> > My view was that it went like this : >> >> > >> >> > >> >> > main starts(args passed in) >> >> > int foo; >> >> > odp_init_t odp_data >> >> > odp_platform_init_t platform_data >> >> > >> >> > /*Process the arguments passed in as normal.*/ >> >> > loop { >> >> > Set variables that main will use itself i.e. if --use-foo is passed >> >> > set >> >> > foo=true locally. >> >> > Prepare odp_data to pass things into the implementation that ODP >> >> > specifies, <- the internals of odp_data may be an argv string or a >> >> > tidy >> >> > struct we define populated by an ODP helper >> >> > Prepare platform_data packaging any params required into the >> >> > platform >> >> > specific struct. <- Have no idea what these are, platform needs to >> >> > figure >> >> > this out >> >> > } >> >> > >> >> >> >> Not sure I understood your proposal/pseudo flow completely. >> >> >> >> = Are you suggesting processing argument twice one for platform_init >> >> second for odp thread? >> >> >> > no, all arguments into main are processed once up front, they are either >> > 1. recorded with local variables as appropriate >> > 2. stuffed into odp_init - maybe with the helper >> > 3. stuffed into odp_platform_init however that platform specifies it >> > should >> > be done. >> > >> > >> >> Which mean ignore old way of argument processing using odp shmem? right. >> >> >> > call global init(odp_data, platform_data) with the above >> >> > >> >> > ........ >> >> > >> >> > /* Act on any remaining parameters such as foo. */ >> >> > if (foo) >> >> > >> >> > >> >> > -- >> >> > Mike Holmes >> >> > Linaro Technical Manager / Lead >> >> > LNG - ODP >> > >> > >> > >> > >> > -- >> > Mike Holmes >> > Linaro Technical Manager / Lead >> > LNG - ODP > > > > > -- > Mike Holmes > Linaro Technical Manager / Lead > LNG - ODP _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
