From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B8D19A0547; Tue, 26 Oct 2021 14:59:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8379340E0F; Tue, 26 Oct 2021 14:59:16 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id CA914407FF for <dev@dpdk.org>; Tue, 26 Oct 2021 14:59:15 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 389185C02F5; Tue, 26 Oct 2021 08:59:15 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 26 Oct 2021 08:59:15 -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= Yo6mJen9c7misuwDKsk4jMpIWNyQhEXZVO1ge4JMWn4=; b=OYr5V3PNMO+Ft6f2 Nl500d2QPVBcV+BqxHQMFEAdlv1jRG8ll2Y6nOaj/b7SabTNNJnLzfykYBd3sTsV qddYjf3Q4arlKzXCq1wGX2QzvbIjjcVCXNzdrIMm52edwH/LmUkZRFePM4+8JAq9 g0pYExCK/MxkPgMFlb5d+FFECTVi6TjH5pgsoMHyzgej/i0/zvOM35agBvRfrqlv nyV27dDWGqStqzxZ7BbYNJ2xm1TH4F3HM+uIRqgloLhvsbcoX7h0eB31E43nk1F8 5pKdQ7VC3jxOEaFqh7hvTIj5iAWz1NYALKEHJ29xv7lzGjbeR7wtU/g2d4Q60ncP aJya7A== 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=Yo6mJen9c7misuwDKsk4jMpIWNyQhEXZVO1ge4JMW n4=; b=fZjnRkksfZWqIxh+/walHvHslZBnjDR6Rb2YXBEoAa6lfTMk6xJt2jWub txhwZHNMR2EA6yy4UrzjsRk8ZmJZ/KB1zvC1c+CkKQ8AbOW3TrWtp6qJK32d0Ima DqXDQkCG0nqoigXiCv5VbJH54o/yC9Cncd9JaqnjZ6uNa5y5e9pyrPL46rLYX/Vn h75n/YuhJSepiasTkmeXYzbJZ5zW2Re3kY6NEBDRsoiDrA3JqgBIl/opK3KwsSvH BEyLFr1nhT0VcwKtwYo9WZh3qVyoN7Y64BwcBm+q4EHmK8lV2oSfrvNB1t1jABfT 3BG3Uh5OZD4gRuVadhz1ZuY8jjwUQ== X-ME-Sender: <xms:ovt3YdEpYhxdDgVzvJ0nriy-CddiV3cE-ieH_7Y1J1lNlV2l7kfQ0Q> <xme:ovt3YSWw_1nliaLctsxa8QqqNTkSmNkbYLCwzOfnPIavAgepwhQgKY7Hh2p7HVXLH KqAvkXt9U6_09OESQ> X-ME-Received: <xmr:ovt3YfKVm3nlE7bOjicNKbTQ-fYGpjzS7IJC6cka8BkM5jKLWiL7G4fN0QPA74Nvl3_qIjQNTGfnAReR7mD96npFjg> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdefkedgfeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepkeethedtieevhfeigeejleegudefjeehkeekteeuveeiuedvveeu tdejveehveetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: <xmx:ovt3YTGw8eudoY49OCAXekkYFgrt_ySluv_rTsQnHMCzBRv3KnvAZg> <xmx:ovt3YTXPo8HB7cehD3uHb4fgHaH2i7m2JrI7_sX_ivT0wbp-J3PTug> <xmx:ovt3YeNzqxrqO_JKkx_MgwBbgPFs_FWrbw5f2jt-sCtp55pSfQsEew> <xmx:o_t3YZzCjkWGPkpyiyj4vKWrTgxX1fkLoaWVAQinI-FzDbzJh_4aTA> Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 26 Oct 2021 08:59:13 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, David Marchand <david.marchand@redhat.com> Cc: Bing Zhao <bingz@nvidia.com>, "Yigit, Ferruh" <ferruh.yigit@intel.com>, "andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>, "dev@dpdk.org" <dev@dpdk.org> Date: Tue, 26 Oct 2021 14:59:12 +0200 Message-ID: <24049921.3QzFLNkSy1@thomas> In-Reply-To: <DM6PR11MB4491226AEFD9F7183D3786D69A849@DM6PR11MB4491.namprd11.prod.outlook.com> References: <20211022211407.315068-1-bingz@nvidia.com> <41930140.NycUuVIHKl@thomas> <DM6PR11MB4491226AEFD9F7183D3786D69A849@DM6PR11MB4491.namprd11.prod.outlook.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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> 26/10/2021 14:38, 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. > > > > > > 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 unintentio= nally. > > > So we need to fix them. > > > I admit that it might be a pain, but it still looks like a one time j= ob to me. > > > With new test-cases we should be able to catch such misbehaving at pa= tch > > > submission stage (by checking then logs). > > > 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 li= ke a > > > right thing, no? Again I expect such test-cases do erroneous rx/tx_bu= rst > > > just few times (not dozens or hundreds) so they shouldn't pollute log= too much. > > > So, what I am missing here? > >=20 > > 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. > >=20 > > > > One thing that could be done is compiling with asserts in CI, and l= et > > > > default build not have those asserts. > > > > > > Agree, log+assert seems like a good alternative to panic() for me. > > > > > > > Otherwise, logging once should be enough (I have a patch for this l= atter idea). > > > > > > 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 l= og message. > >=20 > > 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 attentio= n :) >=20 > Well, that error could come from different sources (rx/tx, different port= s, etc.). > But yes, healthy CI is important. > So if suppressing subsequent messages will help it anyhow, I wouldn't obj= ect. > Few thoughts though: > we probably need to make it more informative (and scary :)) then now: > bump log-level, print current lcore id and dump current call-stack. > Another thought - might be worth to make it logging once per lcore > (instead of global logging once). David tried to print once per queue. I don't know whether it can work. David?