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 28720A034C; Mon, 2 May 2022 23:54:39 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0178640C35; Mon, 2 May 2022 23:54:38 +0200 (CEST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by mails.dpdk.org (Postfix) with ESMTP id 0345B4069D for ; Mon, 2 May 2022 23:54:35 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id D638D3200368; Mon, 2 May 2022 17:54:33 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 02 May 2022 17:54:34 -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=fm1; t=1651528473; x= 1651614873; bh=IrQiSi5b+golBe4ikYxpHm50/azVJgzNn6BPn/ob/AM=; b=t E7ozI0K6AOfo/Nlo8rt0oFUKt68dzUpzTBEcKOT2eZPnQdlJWhrMyCmoTAUFdNg+ iNyrRzWuPDdeEsKOdh20VDS1wAkIJSQXIX8rchHOGufkitkG5iAAo9ASSJUOYSAb XitQxXjx2T2LpenCGddl4A9cWS3rfowzkE+TodzAADRARlhhBuGk2dATuUvQ8yrg KDE62z5te6g9YIpfkdhec/URZ9y04ZFPgJ23rbtPGTfyyVc+08ezaOey88rYZGHt oqJGcIC4T5i6vSOGlYDlMRZIL2XnACD2bbJimspnMGOx/3N/EyRi2NUIsgwyULbu oCS9Z4YpMRHAI4RjynoHw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1651528473; x=1651614873; bh=IrQiSi5b+golB e4ikYxpHm50/azVJgzNn6BPn/ob/AM=; b=PExffsccoKkuCOEvIQVWfIgzZIUPb R9CXLRz2DtxLmlAk/YYud/gqfaBlB/abgN/eVP62KZfmHCjKlMLzoxX1a14iNXNF y3s/gJTDUfb+uU8rXwhseNxcAbUYzUw0yJttciAdeppScW1t11wb0erChh7jDnre 2qkNT0qqY9WLSHMf8Shyulj/crrV58oM1QZSDV1JK1uFoN8vwkZ/hmnu/w83aPNa F9CkTv1DHYRQyKrACSvT+iwjOp3n6hyTmk2Ymb4Him9SFzyHERvO1Mem0baaGhzj U8qIrqBs1Bdz1+M/i3kU0U+QyEky6MJZhJgkJu3e5qQWS6r9OT5MGzV4g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdeigddtvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddtieek gfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 2 May 2022 17:54:32 -0400 (EDT) From: Thomas Monjalon To: "McDaniel, Timothy" Cc: "dev@dpdk.org" , "Van Haaren, Harry" , Jerin Jacob , "Wires, Kent" , david.marchand@redhat.com Subject: Re: rte_bus_probe() does not exit on error Date: Mon, 02 May 2022 23:54:29 +0200 Message-ID: <10320642.NyiUUSuA9g@thomas> In-Reply-To: References: 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 Hello, 02/05/2022 23:20, McDaniel, Timothy: > Hello DPDK community, > > I am following up on a question/comment that I submitted on April 18, for which > I have not received any responses. See the original comment below for context. > > Are there objections to modifying the behavior of rte_bus_probe() so that it propagates > any errors detected while processing the command line arguments? It currently ignores > errors and continues on, always returning success instead of any error that was returned > by the probe function. You are suggesting to stop if probing of one device fails. I am not sure it is a good idea, because sometimes we are OK to proceed even if one device is missing. We could differentiate a fatal error like parsing syntax, and "normal error" of a device which cannot be probed in some conditions. > > -----Original Message----- > > Hello DPDK community, > > > > We are looking into an issue where we pass an invalid command line argument > > to a vdev, and we print out an error message but don't exit. This is an issue with > > all of the command line options that we handle in dlb2_parse_params(). In a > > nutshell, it looks like when we encounter an error in parsing, the error code is > > propagated to event_dlb2_vdev_probe() (event_dlb2_pci_probe() for PF), which > > is called by EAL during device probe in rte_bus_probe(). The problem is that > > rte_bus_probe() calls the .probe function for each device but doesn't exit on > > error: > > > > if (vbus) { > > ret = vbus->probe(); > > if (ret) > > RTE_LOG(ERR, EAL, "Bus (%s) probe failed.\n", vbus->name); > > } > > return 0; > > > > We want to exit if the command line arguments can't be parsed, so we have a > > couple of options: > > > > > > 1. In the DLB PMD, if we get an error while parsing parameters, exit right > > away. > > 2. Change the behavior of rte_bus_probe() so that it propagates the error, > > which causes the program to exit due to EAL error. > > > > if (vbus) { > > ret = vbus->probe(); > > if (ret) { > > RTE_LOG(ERR, EAL, "Bus (%s) probe failed.\n", vbus->name); > > return ret; > > } > > } > > return 0; > > > > Any preference, or other ideas? Option 1 is simple and contained in our code, > > but does call rte_exit() from library code. I'm not sure if that's really an issue > > because we do want to exit if the DLB-specific options are malformed. Option 2 > > is simple and seems like a better option, but requires changes outside of DLB, so > > may be more difficult to upstream? (There may be reasons why the error is > > ignored for some devices). Let me know what you think. > > > > Thanks you for your comments, > > Tim McDaniel