From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 667B6A04C0;
Tue, 29 Sep 2020 13:47:46 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 7A74D1D725;
Tue, 29 Sep 2020 13:47:44 +0200 (CEST)
Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com
[66.111.4.224]) by dpdk.org (Postfix) with ESMTP id A99561D725
for <dev@dpdk.org>; Tue, 29 Sep 2020 13:47:41 +0200 (CEST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
by mailnew.nyi.internal (Postfix) with ESMTP id 50A9B580826;
Tue, 29 Sep 2020 07:47:37 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
by compute1.internal (MEProxy); Tue, 29 Sep 2020 07:47:37 -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=fm2; bh=
k2XNs2GCyVqFS//ChxdlrA2Dap8Xmfxnt4vbAKjwgho=; b=wJI7a5dGSVBC7dzA
bhj/IbUuEPcq1PtJvCnTyCwCj901QdnboJuQYQt1Rv73lSQeM9t3a+K25g+Y+huL
ibGyRvtNWXFpgOVZLL4+0Afml9R37PkhSG12nFonhiHBeeB4FFOBcgaF3IvtnbuE
6Y8A30VnuMOfxEdCDw3Qccz4XmhXGwuatuK3ndHIZYbMAcSFMLPFdQt//zLFQtt8
7nYsDyta2duXIT+akD1RE1y9G1b3HPBXOW77YYY3Yz0Tog2+7Fcmc+IzlptVw6wl
eaZDhcE2V1EgbeV+x1T5EXs0qKNJBvajWH1+IqgeD1WKjv4SPCp88BJSTZ5RwdGw
H73sag==
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=fm3; bh=k2XNs2GCyVqFS//ChxdlrA2Dap8Xmfxnt4vbAKjwg
ho=; b=YS2vxJejkTA/zMdPhLDdk1ohHQWrqjXTbWifTo5MIfjXwe+3RpM+riSHj
P7Eo5/rsIvqeOmjmoAT/cS44Ct+HpWByt3fFDvBptFT5M3m37yjixQQ08b+pZB3g
1dn7cTB8INh7sH9pKZVqdslKi6+Ypz5i00767GUggAOMx4UMmSyOrM6yKmURXYI8
z3DOjri06k3V4WQIGp14RF/a2FLDvzdzKws3nOmanSYJHCAfEmiRxKmz1kyPgGas
zX+tYZ08eqYa4zSXFxP3KXiOwdhcNTDmgrPmuAqqKpbkMY+oRLV0CCIWztsuRsVl
PK2D8wwWQPPEq+qrCxott/2qZobuw==
X-ME-Sender: <xms:2B5zX98L-HUxfyGXTd7K3Skleno2b2aypV5pr6e2gj_-8Or58q1orQ>
<xme:2B5zXxuE0bAPL4xme6JGSucQHuMB_raDyQOr_qJwrfR5eIpBYLZE1owWXf0JQYIAa
E6TUsyL9Mj98t8ofg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdekgdeghecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs
ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf
frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei
iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih
iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho
nhdrnhgvth
X-ME-Proxy: <xmx:2B5zX7DZKbA9rvH5g5Ao6137c1vL8yHMzW7uAt7RMnQDR9jmzgp_8A>
<xmx:2B5zXxc8iS6aeGIFCOTjUR6bZoRWwI0uGOlwIm9QEL23hcAvWbllAw>
<xmx:2B5zXyME46_nPNO6A5i0xlj6Bb8OUtGQfKoYwRvP4RCMrE40akkh1Q>
<xmx:2R5zX3ylJwbci7c88umJQ_k1Irwfl5ttqdCMVMTUNTcMd09t-8UuJg>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
by mail.messagingengine.com (Postfix) with ESMTPA id 6CFB4306467D;
Tue, 29 Sep 2020 07:47:34 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Andrew Rybchenko <arybchenko@solarflare.com>
Cc: dev@dpdk.org, ferruh.yigit@intel.com, Liron Himi <lironh@marvell.com>,
Ray Kinsella <mdr@ashroe.eu>, Neil Horman <nhorman@tuxdriver.com>,
Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>, Gaetan Rivet <grive@u256.net>,
Jakub Grajciar <jgrajcia@cisco.com>, Matan Azrad <matan@nvidia.com>,
Shahaf Shuler <shahafs@nvidia.com>,
Viacheslav Ovsiienko <viacheslavo@nvidia.com>, Zyta Szpak <zr@semihalf.com>,
Stephen Hemminger <sthemmin@microsoft.com>,
"K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>,
Long Li <longli@microsoft.com>, Maxime Coquelin <maxime.coquelin@redhat.com>,
Chenbo Xia <chenbo.xia@intel.com>, Zhihong Wang <zhihong.wang@intel.com>
Date: Tue, 29 Sep 2020 13:47:32 +0200
Message-ID: <2950783.NWLOan7DQ0@thomas>
In-Reply-To: <c24a651c-b8d4-518b-5004-d6f906e46d2d@solarflare.com>
References: <20200913220711.3768597-1-thomas@monjalon.net>
<20200928231437.414489-30-thomas@monjalon.net>
<c24a651c-b8d4-518b-5004-d6f906e46d2d@solarflare.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [PATCH v3 29/29] ethdev: allow close function to
return an error
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
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>
29/09/2020 13:05, Andrew Rybchenko:
> On 9/29/20 2:14 AM, Thomas Monjalon wrote:
> > The API function rte_eth_dev_close() was returning void.
> > The return type is changed to int for notifying of errors.
> >
> > If an error happens during a close operation,
> > the status of the port is undefined,
> > a maximum of resources having been freed.
[...]
> > @@ -135,7 +135,6 @@ Deprecation Notices
> > invalid port ID, unsupported operation, failed operation):
> >
> > - ``rte_eth_dev_stop``
> > - - ``rte_eth_dev_close``
>
> Many thanks for continuing my unfinished job.
It is not finished.
Would you take rte_eth_dev_stop?
> > rte_pmd_mvneta_remove(struct rte_vdev_device *vdev)
> > {
> > uint16_t port_id;
> > + int ret = 0;
> >
> > RTE_ETH_FOREACH_DEV(port_id) {
> > if (rte_eth_devices[port_id].device != &vdev->device)
> > continue;
> > - rte_eth_dev_close(port_id);
> > + ret = rte_eth_dev_close(port_id);
>
> I guess |= should be used here as well (similar as above).
Yes
> > -void
> > +int
> > rte_eth_dev_close(uint16_t port_id)
> > {
> > struct rte_eth_dev *dev;
> > + int ret;
> >
> > - RTE_ETH_VALID_PORTID_OR_RET(port_id);
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
> > dev = &rte_eth_devices[port_id];
> >
> > - RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_close);
> > - (*dev->dev_ops->dev_close)(dev);
> > + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_close, -ENOTSUP);
> > + ret = (*dev->dev_ops->dev_close)(dev);
> >
> > rte_ethdev_trace_close(port_id);
> > - rte_eth_dev_release_port(dev);
> > + ret = rte_eth_dev_release_port(dev);
>
> It does not look good that it overwrites close return status.
Indeed, it seems I did not finish this patch,
or maybe I was drunk ;)
What do you think is the best strategy?
I think we must call rte_eth_dev_release_port()
even if dev_close returns an error.
Then which error to return? I would return the first non-zero one.