> > <snip> > > > > > <more snip> > > <triple snip> > > > > > If I understand the intent of the test case correctly, the > > > > sequence of the calls needs to be: > > > > rte_service_runstate_set(id, 0) > > > > rte_service_component_runstate_set(id, 0); > > > > rte_service_may_be_active - loop till the service is not active > > > > rte_service_lcore_stop(slcore_id); > > > > > > No need to change service runstates, unmapping the service lcore to > > > the service allows service_lcore_stop() to work as expected, and not > > > return - EBUSY. This change to add an unmap() is integrated in the > > > test case in the v2 patch. > > Ok, understood. > > Looking at the patch, why not use the 'rte_service_lcore_stop' to > > provide the status of the lcore? > > For ex: the 'thread_active' can be used in 'rte_service_lcore_stop' to > > indicate that the lcore is still busy? > > Heh - we think alike it seems, v1 of patch had that :) > http://patches.dpdk.org/patch/74493/ > Actually, the looping mechanics and things was inspired by your initial > solution. > > Based on Lukasz's feedback, changing the API behavior isn't nice, and indeed I > kind of agree looking at it now. Adding a concept to check if the core is > actually done is useful, and allows the user to do custom checks. Lukasz's > feedback on the v1 sums it up better than I'll type here. Thanks for pointing out. A separate API sounds better. This is also in line with 'rte_service_may_be_active' API. I have few comments on v2, will send them out.
> > <snip>
