From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B50A6A00C2; Mon, 26 Sep 2022 16:36:12 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 636AD40DF7; Mon, 26 Sep 2022 16:36:12 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id D36634069B for ; Mon, 26 Sep 2022 16:36:10 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 816C95C00E2; Mon, 26 Sep 2022 10:36:10 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 26 Sep 2022 10:36:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1664202970; x= 1664289370; bh=T8TJoSLYx8M1scWU1EPdEZLme0py4UgCkxn00VV2JwY=; b=j qtFLj7wCioQDm4PCpXT72OG4pm9FyejWKE/gucwiLAAzE752O6QexX0Rz/5L7CVz oWggdPY48AyxlpNyPdt++CgRgJ0zXtXVMzAhwEQ6dmC55cIGg9CU8APgUOb3yG8w 3g9Bg6cfxeuIqfHPX6Yn5QKQW+CqxV+OWXL/QZZjisLpMNOC7OP6RR9Woa1EQRox WO+Dm/smbC+JXl05pzJ3X1a9efiVk4klEMzLvo29zpe6mWDJDZQVPnut6V978+dG I2y2xdxzRV7mHoDiwTwEg3oceBS5ToTzhQD4IFA3D/iQadTvSUhBjtvTOAIms0Qq Ub8GNn05TjGPyeBspW1AQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1664202970; x= 1664289370; bh=T8TJoSLYx8M1scWU1EPdEZLme0py4UgCkxn00VV2JwY=; b=J hnEQy4cHFbdMRg5ls0QtmsH5OPh8cbYXVqEqjbeTlKsO3p/SMPZlmieaynrGFC9h nq7xfSm2ha63/x7dkTCuXb+Qxxo0XaYGvaxwsYaUwt7ggRYaLopyJWP/vS6afdKj h7afD1ppXkW3WaAkj6bkzCDnhVrYBKrYNbi6vNUTRgA1RyC5+qt+N3Ar+fJida+o LYR5TlW8mcu1hqA2v9Gk38OY5V+UvK/ESGgm69uNSmHE9VMhbPHP3yEMQMseAYCP Ga4LvuWJqARk4hiG9Rx9ZHVmvH5lA26RnEaTNkBJWOQRWEKPdbAh9KrrgBpt+uIG nW3z919ns42lld1o1UZVA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeegvddgjeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 26 Sep 2022 10:36:09 -0400 (EDT) From: Thomas Monjalon To: Matan Azrad , Andrew Rybchenko , Ferruh Yigit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] ethdev: avoid unregistering a non-allocated callback Date: Mon, 26 Sep 2022 16:36:07 +0200 Message-ID: <6821830.18pcnM708K@thomas> In-Reply-To: <3e53ea11-02c7-4137-917a-505ef0343740@intel.com> References: <20210713131714.964500-1-thomas@monjalon.net> <4457539.Pa9PMCDbyH@thomas> <3e53ea11-02c7-4137-917a-505ef0343740@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org This patch is abandoned. Current behaviour is kept. 15/07/2021 11:06, Ferruh Yigit: > On 7/14/2021 4:42 PM, Thomas Monjalon wrote: > > 14/07/2021 16:16, Matan Azrad: > >> From: Thomas Monjalon > >>> 13/07/2021 15:42, Matan Azrad: > >>>> From: Thomas Monjalon > >>>>> When registering a new event callback, if allocation fails, there is > >>>>> no need for unregistering the callback, because it is not registered. > >>>>> > >>>>> Fixes: 9ec0b3869d8d ("ethdev: allow event registration for all > >>>>> ports") > >>>>> Cc: stable@dpdk.org > >>>>> > >>>>> Signed-off-by: Thomas Monjalon > >>>>> --- > >>>>> --- a/lib/ethdev/rte_ethdev.c > >>>>> +++ b/lib/ethdev/rte_ethdev.c > >>>>> @@ -4649,8 +4649,6 @@ rte_eth_dev_callback_register(uint16_t > >>>>> } else { > >>>>> rte_spinlock_unlock(ð_dev_cb_lock); > >>>>> - rte_eth_dev_callback_unregister(port_id, event, > >>>>> - cb_fn, cb_arg); > >>>> > >>>> Please pay attention to the case of port_id=RTE_ETH_ALL where the user > >>> wants to register the event for all the ports. > >>>> > >>>> In this case, when a failure happens for one of the ports, this unregister call > >>> cleans the callback from all the ports. > >>> > >>> Yes I missed it. Now I better understand the intent, thanks. > >>> > >>> Next question: do we really want to rollback already registered ports? > >>> Anyway, if we are out of memory, I think it is better not doing more > >>> operations. > >>> There can be various opinions on this topic, please give yours. > >> > >> Sure, > >> I understand that memory error is serious, > >> Do you think it is a fatal error? If so, maybe we should use rte_exit? > > > > We don't call rte_exit in the lib, so the app can do whatever it wants. > > > > +1 > > >> That way or others, I think the behavior should be a convention for all the file functions(at least). > > > > What do you mean "all the file functions"? > > > >> I tend to do cleanup on any error. > > > > I would like to hear opinions from others as well. > > > > I also tend to do the cleanup, since API returns error I think application will > be right to think that no callback registered, partially registered callbacks on > error can be confusing.