> -----Original Message----- > From: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com> > Sent: Tuesday, July 21, 2020 4:09 PM > To: Van Haaren, Harry <harry.van.haa...@intel.com>; Lukasz Wojciechowski > <l.wojciec...@partner.samsung.com>; Phil Yang <phil.y...@arm.com>; Aaron > Conole <acon...@redhat.com> > Cc: David Marchand <david.march...@redhat.com>; Igor Romanov > <igor.roma...@oktetlabs.ru>; dev <dev@dpdk.org>; Yigit, Ferruh > <ferruh.yi...@intel.com>; nd <n...@arm.com>; Honnappa Nagarahalli > <honnappa.nagaraha...@arm.com>; nd <n...@arm.com> > Subject: RE: [dpdk-dev] Random failure in service_autotest > > <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. <snip>
