DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
	Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>,
	Phil Yang <Phil.Yang@arm.com>,
	"Aaron Conole" <aconole@redhat.com>
Cc: David Marchand <david.marchand@redhat.com>,
	Igor Romanov <igor.romanov@oktetlabs.ru>, dev <dev@dpdk.org>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>, nd <nd@arm.com>,
	nd <nd@arm.com>
Subject: Re: [dpdk-dev] Random failure in service_autotest
Date: Tue, 21 Jul 2020 15:38:11 +0000	[thread overview]
Message-ID: <BYAPR11MB314322BD167EDC1F2BD32482D7780@BYAPR11MB3143.namprd11.prod.outlook.com> (raw)
In-Reply-To: <DB6PR0802MB2216A275FD0C3BB5CCD4E88198780@DB6PR0802MB2216.eurprd08.prod.outlook.com>

> -----Original Message-----
> From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Sent: Tuesday, July 21, 2020 4:09 PM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>; Lukasz Wojciechowski
> <l.wojciechow@partner.samsung.com>; Phil Yang <Phil.Yang@arm.com>; Aaron
> Conole <aconole@redhat.com>
> Cc: David Marchand <david.marchand@redhat.com>; Igor Romanov
> <igor.romanov@oktetlabs.ru>; dev <dev@dpdk.org>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; nd <nd@arm.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; nd <nd@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>

  reply	other threads:[~2020-07-21 15:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-15 10:14 David Marchand
2020-07-15 10:41 ` Ferruh Yigit
2020-07-17  8:56   ` David Marchand
2020-07-17 15:19     ` David Marchand
2020-07-17 20:31       ` Lukasz Wojciechowski
2020-07-17 22:38         ` Aaron Conole
2020-07-17 22:43           ` Honnappa Nagarahalli
2020-07-18  8:34           ` Phil Yang
2020-07-20 12:09             ` Van Haaren, Harry
2020-07-20 12:47               ` Lukasz Wojciechowski
2020-07-21  5:39                 ` Honnappa Nagarahalli
2020-07-21  8:01                   ` Van Haaren, Harry
2020-07-21  8:07                     ` David Marchand
2020-07-21  8:16                       ` Lukasz Wojciechowski
2020-07-21 15:09                     ` Honnappa Nagarahalli
2020-07-21 15:38                       ` Van Haaren, Harry [this message]
2020-07-21 16:21                         ` Honnappa Nagarahalli
2020-07-15 12:56 ` Aaron Conole
2020-07-15 13:02   ` David Marchand
2020-07-15 13:09     ` Lukasz Wojciechowski
2020-07-15 13:28       ` David Marchand
2020-07-15 13:39         ` Aaron Conole
2020-07-15 20:26           ` Honnappa Nagarahalli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BYAPR11MB314322BD167EDC1F2BD32482D7780@BYAPR11MB3143.namprd11.prod.outlook.com \
    --to=harry.van.haaren@intel.com \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=Phil.Yang@arm.com \
    --cc=aconole@redhat.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=igor.romanov@oktetlabs.ru \
    --cc=l.wojciechow@partner.samsung.com \
    --cc=nd@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).