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 00774A0524;
Wed, 5 May 2021 08:52:52 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 0DE4141161;
Wed, 5 May 2021 08:51:36 +0200 (CEST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com
[64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id 4E3F6410F9
for <dev@dpdk.org>; Wed, 5 May 2021 08:51:31 +0200 (CEST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
by mailout.west.internal (Postfix) with ESMTP id 23CAB10E2;
Wed, 5 May 2021 02:51:30 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
by compute2.internal (MEProxy); Wed, 05 May 2021 02:51:30 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
from:to:cc:subject:date:message-id:in-reply-to:references
:mime-version:content-transfer-encoding:content-type; s=fm1; bh=
nGaZR7yKomPcOP/TX/h2YeVlDoTnlpAogPTi4iZo5aM=; b=ISC0mEtHN2k2m2a4
5Ds4QQVgel5IMmcbCoFAVFnhWSPOfoqf8kQKUPiN88APcE1brZiiSXU6bYPRGHP6
2cbb7AbVe076RNharhg+lqWniOSc3J2iRK9IKLtseIt0XirEmRaz/ci4azjE3t+r
7xAeH+Hp2ysM9r1Qyq1H+zh/X1enCKY0lps9eQ4lUegDvdwhwu/afqWmwVOVCRhU
dnI7bDAymP5y6FDfNVVglFL3neHdN5dfxT5+fCOL5A2NzqefZGtWE0GD8Gt4k5Js
PcgD9rMOTIimJ7/tjmnVZoZw/FtL4GAozWqLYWIDliIhR0ky3T8d6HjStv1akyl+
jKNsEA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-transfer-encoding:content-type
:date:from:in-reply-to:message-id:mime-version:references
:subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
:x-sasl-enc; s=fm2; bh=nGaZR7yKomPcOP/TX/h2YeVlDoTnlpAogPTi4iZo5
aM=; b=kfVAe1+E7e/hE3hhnlpqt3HfvGmCNH3FxE9fyivD1PEHCKKsovLfC+WAv
C4kpElxQjU1h3mNd/k67hovU5z76+Jskr2kZ6k7aOTk7+S4YbLlWrm6MrhogPQvo
+DSo23pnCVB6+iUr3XKtaznPGhCylhMQg+l3e4isIJoq7Z0VImrkpGzDSGH/oubH
UwLUJ2gSzaensint03By2tjdpFC4Xjv6LGyJ2feyB7AmbvFmNhI1F6wuQmmnQVCc
cH6Xv5DyHkOYhAhps8yqj286V7U1YKvui+2aAlVI4CyUAhDPHDlvHcYKcN94OMwm
+xJrFhxIfY090emRnvIdZiytq3yfw==
X-ME-Sender: <xms:cUCSYEgrURBL4pPvqpd1lJSHBg2NJt9XH5TZ-NU2x3DqeJZX8h8XVQ>
<xme:cUCSYNA5yH3Y80E9gUiLOOyUYs3OO_7qQ8lbbRS2IB1jghRwtywoAduK9vxZJRb2T
Y4AFPKe1CLcHNNeWQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefjedguddtjecutefuodetggdotefrod
ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
enucfjughrpefhvffufffkjghfggfgtgesthhqredttddtudenucfhrhhomhepvfhhohhm
rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc
ggtffrrghtthgvrhhnpeehhefffffguefhveetueehveeggedtgeegieeuveefhfduiedt
uefhjedthedtheenucffohhmrghinhepughivgdrnhgvthdpfhhrvggvsghsugdrohhrgh
enucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptden
ucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth
X-ME-Proxy: <xmx:cUCSYMHVURUlEJksMtPZjoN6H67CQDusUOv3L98yUp3QXlFogo-duw>
<xmx:cUCSYFTVskoBkSzFEIh5FzGNebv8BlPHpKanaGCX4BM0ULE5HrqduQ>
<xmx:cUCSYBwRgjeGw-I0OOflCVWQh1501wlicpsrHCZQPgKPUjHXtiFTuw>
<xmx:cUCSYJ-cMN7MU_DxW2d8RYGTvsc7YhMt-XoWZeqMGjjxBuh8tLRCsA>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
by mail.messagingengine.com (Postfix) with ESMTPA;
Wed, 5 May 2021 02:51:28 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: "Min Hu (Connor)" <humin29@huawei.com>,
Morten =?ISO-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com>
Cc: dev@dpdk.org, ferruh.yigit@intel.com, skori@marvell.com, jerinj@marvell.com
Date: Wed, 05 May 2021 08:51:27 +0200
Message-ID: <15286141.XL2fGeQaG1@thomas>
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C61747@smartserver.smartshare.dk>
References: <1619597563-56716-1-git-send-email-humin29@huawei.com>
<8952614.77jy4Yh1ug@thomas>
<98CBD80474FA8B44BF855DF32C47DC35C61747@smartserver.smartshare.dk>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Subject: Re: [dpdk-dev] [PATCH v2] eal: fix use wrong time API
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>
05/05/2021 08:26, Morten Br=F8rup:
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Wednesday, May 5, 2021 8:14 AM
> >=20
> > 04/05/2021 21:12, Morten Br=F8rup:
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas
> > Monjalon
> > > > Sent: Tuesday, May 4, 2021 6:50 PM
> > > >
> > > > 29/04/2021 04:10, Min Hu (Connor):
> > > > > Currently, the mp uses gettimeofday() API to get the time, and
> > used
> > > > as
> > > > > timeout parameter.
> > > > >
> > > > > But the time which gets from gettimeofday() API isn't
> > monotonically
> > > > > increasing. The process may fail if the system time is changed.
> > > > >
> > > > > This fixes it by using clock_gettime() API with monotonic
> > > > attribution.
> > > > >
> > > > > Fixes: 783b6e54971d ("eal: add synchronous multi-process
> > > > communication")
> > > > > Fixes: f05e26051c15 ("eal: add IPC asynchronous request")
> > > > > Cc: stable@dpdk.org
> > > > >
> > > > > Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > > > > Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
> > > > > ---
> > > > [...]
> > > > > --- a/lib/eal/common/eal_common_proc.c
> > > > > +++ b/lib/eal/common/eal_common_proc.c
> > > > > - if (gettimeofday(&now, NULL) < 0) {
> > > > > - RTE_LOG(ERR, EAL, "Cannot get current time\n");
> > > > > - goto no_trigger;
> > > > > - }
> > > > > - ts_now.tv_nsec =3D now.tv_usec * 1000;
> > > > > - ts_now.tv_sec =3D now.tv_sec;
> > > > > + clock_gettime(CLOCK_MONOTONIC, &ts_now);
> > > >
> > > > Why not testing the return value?
> > >
> > > Because it is guaranteed not to fail. Ref:
> > > https://linux.die.net/man/3/clock_gettime
> > > https://www.freebsd.org/cgi/man.cgi?query=3Dclock_gettime
> >=20
> > I see "return 0 for success, or -1 for failure".
> > Where is it said it cannot fail?
>=20
> I'm sorry about being unclear. Referring to the "Errors" chapter in the f=
unction's man page, this function call is guaranteed not to fail with these=
parameters. So there is no need to check the return value.
I don't agree.
Especially for this error:
"The clk_id specified is not supported on this system."
How can you be sure it is always supported for any system
we try to run this code now and in future experiments?