From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 7B075A0C4B;
Fri, 20 Aug 2021 10:52:57 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 003EF41139;
Fri, 20 Aug 2021 10:52:56 +0200 (CEST)
Received: from us-smtp-delivery-124.mimecast.com
(us-smtp-delivery-124.mimecast.com [170.10.133.124])
by mails.dpdk.org (Postfix) with ESMTP id 464554013F
for <dev@dpdk.org>; Fri, 20 Aug 2021 10:52:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1629449574;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=07p7tSV9lZWZFeLZ/xiDLw8GKLOnC16ghu7Wl/jQYIQ=;
b=cA83MQR+8OqvtkMlY5xb3Rb6DAZQE1nZWL9FN/24DKd10iA4MrcX13aKI7pTRYEqJDDQMz
ek5pALzE320mfxo4XX9fyzE0lcAOD4/58oVHP1bUQ3gGcQo9+OiU4CveHIsVcNA94BfsEf
qpG39diFzbhRCJtoLZ/zE3/gWkiQnOg=
Received: from mail-vk1-f197.google.com (mail-vk1-f197.google.com
[209.85.221.197]) (Using TLS) by relay.mimecast.com with ESMTP id
us-mta-460-Nn5p1rJJOIaDNU2HekuJBQ-1; Fri, 20 Aug 2021 04:52:53 -0400
X-MC-Unique: Nn5p1rJJOIaDNU2HekuJBQ-1
Received: by mail-vk1-f197.google.com with SMTP id
h8-20020a05612201c8b02902860f027dd8so1518123vko.19
for <dev@dpdk.org>; Fri, 20 Aug 2021 01:52:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=07p7tSV9lZWZFeLZ/xiDLw8GKLOnC16ghu7Wl/jQYIQ=;
b=OGT75dBgIM7xfYbcnjv3HewgYHiQ0WcSYDR/RX3fNkmdrB1FnPWX57xt+8cSuvszCB
qUo/BuLUX+TMSzSmh8ii+JtwO4aUskKZdZa6pif/Vgavdx2z+353tTW5Azs3SVl06dgU
D6F3NSLOHG6amlxRWTna+siDdze0oQ/6al9evbRbTt5XqbjzRDJOkQoxRjcLA++lCbSl
2zYvqELtoM62jPMx9XEpN36JmUtNwOtKm+1qK60mv7NysSsz4+uwGcudseA0THRO1O/w
EhIRh+ScsJ3Kckk8U6LTu9JjVJWkGFoZiuDKqXFM9POMUOYyQIIXRMxZTnN2yo4Z5L2h
Sscg==
X-Gm-Message-State: AOAM533tdXgTAANyS7EGNHQEyELlDF32k4AqO8ldsAWpW9cbz38uEmww
KlWVlAASt/kYkEB0B2uWPubTR/LDMBdedJiZEAfY5a3R/3KKj7RDxCE0S0RFT9Pl+nIWZHCP3l6
k/b6ND3ZwWiVitU8uIfk=
X-Received: by 2002:a67:ec98:: with SMTP id h24mr16193669vsp.10.1629449573151;
Fri, 20 Aug 2021 01:52:53 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJyhIGrxUZNonBmiKNLTBJIEX1KRM0FQOq1N6u+o5E5asQMc6Dzwy0a8B+ubQCo08OB8oShpvYG6J9O3GDbTNMk=
X-Received: by 2002:a67:ec98:: with SMTP id h24mr16193660vsp.10.1629449572870;
Fri, 20 Aug 2021 01:52:52 -0700 (PDT)
MIME-Version: 1.0
References: <20210728073322.27011-1-joyce.kong@arm.com>
<20210731120336.30886-1-joyce.kong@arm.com>
<CAJFAV8xUYgJ_BFEJ0yM6yjKW4k++qQHsv_8zdiTmkP7c0f91fA@mail.gmail.com>
<AS8PR08MB69356DA82734E71A66CA09A692C19@AS8PR08MB6935.eurprd08.prod.outlook.com>
In-Reply-To: <AS8PR08MB69356DA82734E71A66CA09A692C19@AS8PR08MB6935.eurprd08.prod.outlook.com>
From: David Marchand <david.marchand@redhat.com>
Date: Fri, 20 Aug 2021 10:52:41 +0200
Message-ID: <CAJFAV8xPTL9b7H2NhtVOF4Usrzxuv4RqOC1M4Ap7jQ05xATDVA@mail.gmail.com>
To: Joyce Kong <Joyce.Kong@arm.com>
Cc: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
Olivier Matz <olivier.matz@6wind.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, "Wang,
Yipeng1" <yipeng1.wang@intel.com>,
"Gobriel, Sameh" <sameh.gobriel@intel.com>,
Bruce Richardson <bruce.richardson@intel.com>,
Vladimir Medvedkin <vladimir.medvedkin@intel.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
Ruifeng Wang <Ruifeng.Wang@arm.com>, dev <dev@dpdk.org>,
nd <nd@arm.com>, dpdk stable <stable@dpdk.org>,
Aaron Conole <aconole@redhat.com>
Authentication-Results: relay.mimecast.com;
auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [dpdk-dev] [PATCH v2] test/func_reentrancy: free memzones after
creating test case
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
On Fri, Aug 20, 2021 at 9:57 AM Joyce Kong <Joyce.Kong@arm.com> wrote:
>
> > -----Original Message-----
> > From: David Marchand <david.marchand@redhat.com>
> > Sent: Tuesday, August 17, 2021 4:17 PM
> > To: Joyce Kong <Joyce.Kong@arm.com>
> > Cc: Burakov, Anatoly <anatoly.burakov@intel.com>; Olivier Matz
> > <olivier.matz@6wind.com>; Andrew Rybchenko
> > <andrew.rybchenko@oktetlabs.ru>; Wang, Yipeng1
> > <yipeng1.wang@intel.com>; Gobriel, Sameh <sameh.gobriel@intel.com>;
> > Bruce Richardson <bruce.richardson@intel.com>; Vladimir Medvedkin
> > <vladimir.medvedkin@intel.com>; Ananyev, Konstantin
> > <konstantin.ananyev@intel.com>; Honnappa Nagarahalli
> > <Honnappa.Nagarahalli@arm.com>; Ruifeng Wang
> > <Ruifeng.Wang@arm.com>; dev <dev@dpdk.org>; nd <nd@arm.com>; dpdk
> > stable <stable@dpdk.org>; Aaron Conole <aconole@redhat.com>
> > Subject: Re: [dpdk-dev] [PATCH v2] test/func_reentrancy: free memzones
> > after creating test case
> >
> > On Sat, Jul 31, 2021 at 2:04 PM Joyce Kong <joyce.kong@arm.com> wrote:
> > >
> > > Function reentrancy test limits maximum number of iterations
> > > simultaneously, however it doesn't free the 'fr_test_once'
> > > memzones after the fact, so introduce freeing 'fr_test_once'
> > > in ring/mempool/hash/fbk/lpm_clean.
> > >
> > > Meanwhile, add the missing free for test case on main thread.
> > >
> > > Fixes: 104a92bd026f ("app: add reentrancy tests")
> > > Fixes: 995eec619024 ("test: clean up memory for function reentrancy
> > > test")
> > > Cc: stable@dpdk.org
> > >
> > > Signed-off-by: Joyce Kong <joyce.kong@arm.com>
> > > Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > > Reviewed-by: Feifei Wang <feifei.wang2@arm.com>
> >
> > This patch actually breaks the test (we are lucky, the failure happens often ;)).
> >
> > 28/94 DPDK:fast-tests / func_reentrancy_autotest FAIL
> > 0.22s (exit status 255 or signal 127 SIGinvalid)
> >
> > --- command ---
> > 16:13:45 DPDK_TEST='func_reentrancy_autotest'
> > /home-local/jenkins-local/jenkins-agent/workspace/Generic-Unit-Test-
> > DPDK/dpdk/build/app/test/dpdk-test
> > -l 0-15 --file-prefix=func_reentrancy_autotest
> > --- stdout ---
> > RTE>>func_reentrancy_autotest
> > Func-ReEnt CASE 0: eal init once PASS
> > ring create/lookup: common object allocated 2 times (should be 1) Func-
> > ReEnt CASE 1: ring create/lookup FAIL Test Failed
> > RTE>>
> > --- stderr ---
> >
> >
> > I guess, this is what happens:
> >
> > main lcore worker lcore 1 ...
> > worker lcore X
> > enters ring_create_lookup()
> >
> > enters ring_create_lookup()
> > rte_eal_wait_lcore(worker lcore 1);
> > leaves ring_create_lookup() ring_clean(worker lcore 1);
> >
> > leaves ring_create_lookup()
> >
> > There is no synchronisation point for the main lcore to know the worker
> > lcores are finished invoking the func callback.
> > With this patch, the "common" object is freed by the main lcore
> > *potentially* before some workers start trying to create it.
> > And we end up with multiple workers successfully creating this object, hence
> > the obj_count being incremented.
> >
> >
> > --
> > David Marchand
>
> I think add rte_eal_mp_wait_lcore() like below can ensure the lcores to free objects
> after all func callback finished.
> Shall do the change in next version.
>
> RTE_LCORE_FOREACH_WORKER(lcore_id) {
> if (cores == 1)
> break;
> cores--;
> rte_eal_remote_launch(pt_case->func, pt_case->arg, lcore_id);
> }
> rte_atomic32_set(&synchro, 1);
> if (pt_case->func(pt_case->arg) < 0)
> ret = -1;
>
> + rte_eal_mp_wait_lcore();
>
> cores = cores_save;
> RTE_LCORE_FOREACH_WORKER(lcore_id) {
> if (cores == 1)
> break;
> cores--;
> - if (rte_eal_wait_lcore(lcore_id) < 0)
> - ret = -1;
> if (pt_case->clean != NULL)
> pt_case->clean(lcore_id);
> }
Using mp_wait_lcore, the test can't tell if a lcore returned an error
after executing the passed callback.
An alternative is to split the current loop to first have the per
lcore rte_eal_wait_lcore() calls + ret code check, and then a second
loop calls the clean() callback.
--
David Marchand