From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 060112B8C for ; Tue, 6 Dec 2016 11:51:21 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP; 06 Dec 2016 02:51:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,309,1477983600"; d="scan'208";a="14244506" Received: from sthete-mobl2.gar.corp.intel.com (HELO [10.252.13.41]) ([10.252.13.41]) by orsmga002.jf.intel.com with ESMTP; 06 Dec 2016 02:51:18 -0800 To: Qiming Yang , dev@dpdk.org References: <1480761783-36467-1-git-send-email-qiming.yang@intel.com> Cc: Wenzhuo Lu , Helin Zhang , Konstantin Ananyev , Jingjing Wu From: Ferruh Yigit Message-ID: <1cf27486-99cb-1a3d-a067-cd44ac38c333@intel.com> Date: Tue, 6 Dec 2016 10:51:17 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1480761783-36467-1-git-send-email-qiming.yang@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH 0/3] net: optimize Rx/Tx log message level 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: Tue, 06 Dec 2016 10:51:23 -0000 Hi Qiming, On 12/3/2016 10:43 AM, Qiming Yang wrote: > These three patches optimized the level of Rx and Tx log > messages. Add a new log control function PMD_RX_FREE_LOG > to control the Rx message which is not printed in packet > receive processing. This function switched by macro > RTE_LIBRTE__DEBUG_RX_FREE. Please CC the maintainers, CC: Wenzhuo Lu CC: Konstantin Ananyev , Helin Zhang CC: Jingjing Wu 1- Do we really need a new config option just for this log function, we already may have more config options? 2- Do we really need this new logging function at all? This is to report when receive descriptor tail updated, as far as I can see. What is the use case that makes this case so special? 3- Log level of some messages are increased, like mbuf allocation failure message level increased to ERR, what is the expectation here? In high throughput traffic this may cause lots of noise, and what user can do with this message? If user can't do anything, why we bloating user with error messages? There is already a dynamic counter, I believe which is good thing to the for this error, and debug level logging. Overall I am for rejecting this patchset, unless there is a good justification for new debug log macro. Thanks, ferruh