From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 8B7231B48E for ; Sun, 13 Jan 2019 22:21:27 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D5570288B6; Sun, 13 Jan 2019 16:21:11 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 13 Jan 2019 16:21:11 -0500 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=mesmtp; bh=TcjpVhR3YazNyvTcDEgkhrjF+l1ND4gYSnbukLI3ml0=; b=J9nmYAr5OGsw SP4YTsUfYJhEL/Z38UjDwhVIiUOpi2yP4xbAlVQ9xmCL1MMHEAAcKnAJEu5fsYjy yMdJl5QDg5kdjattAmdyTXI5RbZvoVkEDvFmym/UrL+m4TgHS7tnvX28RQrSNhsz 8hvXjum3pSBlLJ95IPuwym8hE/WvzxE= 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=fm1; bh=TcjpVhR3YazNyvTcDEgkhrjF+l1ND4gYSnbukLI3m l0=; b=HSlfcrc3KfdUFIahXB2w9hXLsVoTZLc/7bviw3HZGhQX4fWO7gAW3m177 07p3HdGFNqelP/9iwa0qY63UZnmHdap97I+Rn90Ye0eSWhQB46CZ9TmFc2mSU9AN 4GwDSxM8QRC4xIn89fWmX1ayBte0cCcWwRhbvE5hIZPfH/Cv8n7CHH+uD6DL1J16 J7FyuMc2qvTNwKgnHKynmi7sW/15modr3hprRfArf+5vHSs27Kp+xUeHFeohQg22 S608dVv9Ghg+NMHPnZgGu6V2BrEJVQOiXaw8HZpsJaPtNKpnXQHlZkNZyPCezioF m9mGbfZGhDjPcOYppROSAJ7uKUobg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrfeelgdduhedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufffkjg hfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcu oehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkphepjeejrddufeegrddvtd efrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 8200BE425A; Sun, 13 Jan 2019 16:21:10 -0500 (EST) From: Thomas Monjalon To: "Wiles, Keith" Cc: Nithin Kumar Dabilpuram , "Yigit, Ferruh" , Andrew Rybchenko , "dev@dpdk.org" , Jerin Jacob Kollanukkaran Date: Sun, 13 Jan 2019 22:21:08 +0100 Message-ID: <7520504.p0jQqc19KO@xps> In-Reply-To: <17CD35BA-B70C-4F7C-A90B-636BB02148C8@intel.com> References: <20190107143951.30076-1-ndabilpuram@marvell.com> <8373161.2Fht6qqTaI@xps> <17CD35BA-B70C-4F7C-A90B-636BB02148C8@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] ethdev: report error on name truncation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2019 21:21:27 -0000 13/01/2019 21:19, Wiles, Keith: > > On Jan 13, 2019, at 2:02 PM, Thomas Monjalon wrote: > > 13/01/2019 20:28, Wiles, Keith: > >>> On Jan 13, 2019, at 9:38 AM, Nithin Kumar Dabilpuram wrote: > >>> --- a/lib/librte_ethdev/rte_ethdev.c > >>> +++ b/lib/librte_ethdev/rte_ethdev.c > >>> + if (rc >= RTE_MEMZONE_NAMESIZE) { > >>> + RTE_ETHDEV_LOG(ERR, "truncated name"); > >>> + rte_errno = ENAMETOOLONG; > >>> + return NULL; > >>> + } > >> > >> I we are already returning an error here should the RTE_LOG be DEBUG > >> and not ERR. > >> Of course this does mean we would have to check return codes :-) > > > > In the general case, we should always log the errors as RTE_LOG_ERR, > > no matter it is handled and logged again at an upper level. > > Don't you think so? > > My only concern is cluttering up the console output and developers should be checking return codes, which I know we do not do sometimes in DPDK. > I think we need to do some cleaning up of DPDK and test return codes or make the function return void, but that is a different problem then this one. > > If we are fine with this type of log style then we can leave it. To me is just seem redundant if we are returning a code the calling function should report the error. In some cases we will get two or more messages about the same problem depending on the call path. The log can be different at different levels. The deepest log will give details, while other logs will give context. The more error logs we have, the better it may be for the user. I understand the concern about keeping logs clean, but for errors, I don't see possible redundancy as a spam. Anyone else think differently?