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 6C3F5A0C4B; Mon, 25 Oct 2021 11:43:15 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F410B407FF; Mon, 25 Oct 2021 11:43:14 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id ABDC24003E for <dev@dpdk.org>; Mon, 25 Oct 2021 11:43:13 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 21EB05C00E5; Mon, 25 Oct 2021 05:43:12 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 25 Oct 2021 05:43: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= xBisK5HTes7+uKy2fDvISMp3usHCWj/uyeNSjrsgGHE=; b=o10oYpvEP5KvkHu0 d+ACQa5M1Ef3r/pubEd5uXizAD13P0CzepaZ7YEofAZqkis+zCfkyjhTNTCLtt7D VcPtVVx1P/pmv3Y7LCNNkQ02wmBBWU7z33GDURQJ1icejRmhrZyJqQHcE3vYWoW+ lRz8HIZIQRHq3uGAsmkKO6KX+9JTX1oLhNLHz3zVFfDyF3E9+vQ3om21dWufrdd9 fwyg/0F3Q0dLH1z2lVh0Qh/RnY9h/5gU6r3zYqpfFT9lgmEVuvjEjNyF3CJVATt3 bWn0goSTrZhLMM7ZfOBliSaR/ZiwDoEZvafXafdlfeyccjpmcScF6FO55A5VSU3F tCjbMg== 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=xBisK5HTes7+uKy2fDvISMp3usHCWj/uyeNSjrsgG HE=; b=JgmDifwjCZL2ci00IIG1nJtis3ID6NyPTNuRHl15rqDk3g01Gr6PiTtqw 2dZUGr2LZCmssW8+H062t6VX+mYZMrPFuGMKMSyN9yhd0/Yo7M7iu4hd/5Q7vPZg SsN9n6DDHXW9TeTI6M0xG2rlVZsmENVV5+BKZ58Ge/ZY+voSLBO/fwNZjngIquBs GRE96iGGv9CygnUw+Mk2stexkzdR28x1TQg7hrCvmpXtRCUvkAtelIXC38H5RZ1T yCx5cvo99ft2BJG8xqAnprdeOGZU9X6KXazzpeGJlm73M60NiuOhMvHCjDuM+zqa 0UlcaMIJ+83kt0xKXE8boahX+hewA== X-ME-Sender: <xms:Lnx2Yb-pHdPzApiF4XYOYPjglLM0rUWYH4nqjPdCPX-OyMIs22x6RA> <xme:Lnx2YXv8LPAx-ueoI9Zr9yxZCuRnq54iD6d7RnTdNyKJRyxYrAmnBiQdITnmrXWu1 5kfyOSEnxaOGvxN9Q> X-ME-Received: <xmr:Lnx2YZBawhBEJyGgr-Jmum_QyU5IucleInJ49E3aRaifoU8QlP0ElHEplHnzroiWeA1OUvKte7d1GXrk5hIYcoMJxg> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdefhedgudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: <xmx:Lnx2YXdbwWE4iMRlEz3Z7Qi-_Z39p_glwNOqy6qpjQAArT09y2EoJA> <xmx:Lnx2YQOgeBeqBLT1MrUMXMIRX0fmAMSZfMfguO1OHwUDe8-cDUx3EA> <xmx:Lnx2YZlvyfuqb-ZdXOq-eHOeFUCtBBaoeVoSpRToIA9ms4d_XvaTwQ> <xmx:MHx2YdrESkZRXHB6J7gAZnOsPHfN6a34LQieF7etypCOFFEBJtRCDQ> Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 25 Oct 2021 05:43:09 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: "Ananyev, Konstantin" <konstantin.ananyev@intel.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>, david.marchand@redhat.com Date: Mon, 25 Oct 2021 11:43:08 +0200 Message-ID: <2136748.9NGIIKDUHm@thomas> In-Reply-To: <DM6PR11MB44913D01F3D28EE374059FF59A829@DM6PR11MB4491.namprd11.prod.outlook.com> References: <20211022211407.315068-1-bingz@nvidia.com> <DM5PR12MB1755717BCD34B643F66BDCFFD0819@DM5PR12MB1755.namprd12.prod.outlook.com> <DM6PR11MB44913D01F3D28EE374059FF59A829@DM6PR11MB4491.namprd11.prod.outlook.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 <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> 24/10/2021 13:48, Ananyev, Konstantin: > > > > > > When stopping a port, the data path Tx and Rx burst functions > > > should > > > > > be stopped firstly conventionally. Then the dummy functions are > > > used > > > > > to replace the callback functions provided by the PMD. > > > > > > > > > > When the application stops a port without or before stopping the > > > > > data path handling. > > > > > > If the application really does that, then it is a severe bug in the > > > application, then needs to be fixed ASAP. > > > > I agree, this should be some improper / wrong behavior in the application. > > > > > > > > > The dummy functions may be invoked heavily and a lot > > > > > of logs in these dummy functions will result in a flood. > > > > > > > > Why does it happen? We should not use a stopped port. > > > > Is it a problem of core synchronization? > > > > > > > > > Debug level log should be enough instead of the error level. > > > > > > > > > > > > > > Dummy function is supposed to be set only when device is not able to > > > do RX/TX properly (not attached, or attached but not configured, or > > > attached and configured, but not started). > > > Obviously if app calls rx/tx_burst for such port it is a major issue, > > > that should be flagged immediately. > > > So I believe having ERR level here makes a perfect sense here. > > > > I do not insist on this. Some notification to the application may be needed. While to my understanding, the log flood should be prevented, > > or the logs may slow down the application, the IO, and would also have impact on other logs and some information may get lost (but that is > > the users' decision). > > Since the rx/tx burst are usually in the data path and invoked heavily, if the log is needed, how about print it only once? WDYT? > > > > 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. There is a concern about getting efficient log report, especially when looking at CI issues.