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 EA075A0C47; Mon, 25 Oct 2021 22:38:35 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B114841159; Mon, 25 Oct 2021 22:38:35 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id AD5194003E for ; Mon, 25 Oct 2021 22:38:33 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1176D5C025D; Mon, 25 Oct 2021 16:38:33 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 25 Oct 2021 16:38:33 -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= 0ApKPmeFw+iSFtDC+3xr+UafVpoBstQERYqRdwrF2/0=; b=TX42L1yEKeoOZErO TKD//j6Lhbb4BXfdxQXqFIDlGggOl8OEEAaaB2h4NpOD8dStRa2oZm9ucwzUMGTx tp7f27yKStgVzwG3bvn+EtBV6NwwUQrZ04o7WxLVfwN5rsjIw0d15fHaYzu06KK9 EfV2GH1i6kYlyeJDcGSzaducc12ne2HedGNP3GKZtPgtP+picbr3+iYnIBTITJQI 7a6VcEULlUTvITnnkvSdvSG5GUaEq3fm6GlGSnpdpRSmCFnRqce7Fp45yJeOzWkB QtKSNOVRtxCgRdQ4yYVPX2o9updEq/+tDEvydvwfXFQhZLOQTSiD4X2VOnTgikjl s+5w0g== 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=0ApKPmeFw+iSFtDC+3xr+UafVpoBstQERYqRdwrF2 /0=; b=ECa8Gjyz/YmZ50uB3irDr6A5LGPyBzUwv1VqMFb9jZUWYZ3EWcVxvu2eC XDSwlHf/oue8I8IqE9DqhKT/1VlqMvRSaMFaZUKy8kyIh/s9rKAu9LKnNy5Af2mQ eWEy1z5sZ+bnhNA4aGs8NtqF9bv4zd5VtvaYaSFKFaniDrSGToOTpfkjeX9sTMId GdpkRgcbFzCNAuEntGEjERPEgOgve6PrvIhihINckNV56HqdtG28SYvbkJ5nKzZ6 8Lij5lCqCm/c4nb8Co1WxBK7aCFg048s7cNcA1dsbS3npRwwkAIztsPd0Vxy4+QL gQuu4U8KhbtBV1PUhBr/7zXwE/TxA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdefhedgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeekteehtdeivefhieegjeelgedufeejheekkeetueevieeuvdev uedtjeevheevteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 25 Oct 2021 16:38:31 -0400 (EDT) From: Thomas Monjalon To: "Ananyev, Konstantin" Cc: David Marchand , Bing Zhao , "Yigit, Ferruh" , "andrew.rybchenko@oktetlabs.ru" , "dev@dpdk.org" Date: Mon, 25 Oct 2021 22:38:29 +0200 Message-ID: <41930140.NycUuVIHKl@thomas> In-Reply-To: References: <20211022211407.315068-1-bingz@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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 22:29, Ananyev, Konstantin: >=20 > > > > > > 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. >=20 > It is still not clear to me why it is going to be a recurring one? > Ok, right now we have some test-cases that are misbehaving unintentionall= y. > So we need to fix them. > I admit that it might be a pain, but it still looks like a one time job t= o me. > With new test-cases we should be able to catch such misbehaving at patch > submission stage (by checking then logs). =20 > I guess there might be some test-cases that misbehave intentionally - > some negative test-cases for error-condition checking etc. > But for them error message in the log and error return value seems like a > right thing, no? Again I expect such test-cases do erroneous rx/tx_burst > just few times (not dozens or hundreds) so they shouldn't pollute log too= much. > So, what I am missing here? You don't miss anything, but as you said above, we are going to catch some issues at patch submission stage. And we want this stage to be easy to catch. Having megabytes of log does not help to check in the CI. > > One thing that could be done is compiling with asserts in CI, and let > > default build not have those asserts. >=20 > Agree, log+assert seems like a good alternative to panic() for me. >=20 > > Otherwise, logging once should be enough (I have a patch for this latte= r idea). >=20 > I understand the intention, but I am a bit sceptical about that one: > it is quite often people don=E2=80=99t pay much attention to single log m= essage. Not a good argument in my opinion. One error =3D=3D one log. We are not going to flood all error logs to make sure devs pay attention :)