Re: [dpdk-dev] Random failure in service_autotest

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>]

> > <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>