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 60721A0C4C; Mon, 25 Oct 2021 15:27:15 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DB70240E32; Mon, 25 Oct 2021 15:27:14 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 6A6E24003E for ; Mon, 25 Oct 2021 15:27:13 +0200 (CEST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E6B995C01E6; Mon, 25 Oct 2021 09:27:12 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Mon, 25 Oct 2021 09:27:12 -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= twwFETl4VNS/e9bIyt22OMENYzKAzlkd0pDFFdTG4L0=; b=NJB7xCqj4HrtqoJu W+BYbf4agjpJyE07Isx9O4N99nxIdwRl4QFd9ohpsQGXKns9pouOyHYM2FYxGnN0 6DAXUc8bJ2E5JYhBLmXKWHaoiFhWdaOGiToJc7IHJtbMNfQY472TsJumofFwyNR+ P+Ttcfa9GybKz3PL6wuM+/zuvyOeOzPD9tGkZAc96X0auZ+J7dxL8evB5C7GqU8N xzGOr0NqXKh48Wwlsz7DtWh+Kv0nwaEoNR3h5EFBMq3RHxB57pbphCMKIsEudOMq mqdvPRUoK5RxLQ27an/mQ4pMATl28P4p7AxGJDX7mxhIVh2uLfar4bgE+idNi1EL 4eXSjA== 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=twwFETl4VNS/e9bIyt22OMENYzKAzlkd0pDFFdTG4 L0=; b=aKRTjfPQoRWHQB2BFHzWL1ddcN9fMWyRRPE4ZY6B/OGiY6Tj8LhPypsgk CHUCHYuSgJcA8y5092IxBtqUj+HRXhe18BRHxO7uoG1yn6SIHecA/9x7dCTbFmuc 8dqwq7FeqscUIGhHxBvxrsZk4ORfxP4Mw3X1K1/scBciaSgNikB8lhjRb9sfGwhk EClk2stAqfxrkUbAu1f9U1cpZbvFvgfzLkRpRX0NL9RNzJfVaHaAMmd+ipD8d66U CS/1b4BpCkC887ErHGhXX4g2ZtuYxBzAbArjUz30ZA60kgmBvy6SblWwv//gfgzI XcMb13te8dorxXrAtis4jA2zkxXlQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdefhedgiedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 25 Oct 2021 09:27:11 -0400 (EDT) From: Thomas Monjalon To: David Marchand , "Ananyev, Konstantin" Cc: Bing Zhao , "Yigit, Ferruh" , "andrew.rybchenko@oktetlabs.ru" , "dev@dpdk.org" Date: Mon, 25 Oct 2021 15:27:09 +0200 Message-ID: <9793508.3ULvtkr7ud@thomas> In-Reply-To: References: <20211022211407.315068-1-bingz@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: fix log level of Tx and Rx dummy functions 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 Sender: "dev" 25/10/2021 14:55, Ananyev, Konstantin: > > > > > Correctly behaving app should never call these stub functions and should never see these messages. > > > > If your app ended up inside this function, then there something really wrong is going on, > > > > that can cause app crash, silent memory corruption, NIC HW hang, or many other nasty things. > > > > The aim of this stubs mechanism: > > > > 1) minimize (but not completely avoid) risk of such damage to happen in case of > > > > programming error within user app. > > > > 2) flag to the user that something very wrong is going on within his app. > > > > In such situation, possible slowdown of misbehaving program is out of my concern. > > > > If correctly behaving app should not do this, why not put an assert() > > or a rte_panic? > > This way, the users will definitely catch it. > > That was my first intention, though generic DPDK policy is > to avoid panics inside library functions. > But if everyone think it would be ok here, then I am fine with it too. I would prefer not having panic/assert in the lib. > > > There is a concern about getting efficient log report, > > > especially when looking at CI issues. > > > > +1. > > The current solution with logs is a real pain. > > Are you guys talking about problems with > app/test/sample_packet_forward.* David reported? > Or some extra problems arise? The problem will arise each time an app is misbehaving. That's going to be a recurring problem in the CI.