From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id A36D7FC24 for ; Thu, 30 Mar 2017 03:51:56 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga105.jf.intel.com with ESMTP; 29 Mar 2017 18:51:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,244,1486454400"; d="scan'208";a="1128718286" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by fmsmga001.fm.intel.com with ESMTP; 29 Mar 2017 18:51:53 -0700 Date: Thu, 30 Mar 2017 09:49:34 +0800 From: Yuanhan Liu To: "Legacy, Allain" Cc: "mtetsuyah@gmail.com" , "maxime.coquelin@redhat.com" , "dev@dpdk.org" , "Peters, Matt" , Thomas Monjalon , Bruce Richardson Message-ID: <20170330014934.GL18844@yliu-dev.sh.intel.com> References: <20170327162930.54281-1-allain.legacy@windriver.com> <20170328064841.GZ18844@yliu-dev.sh.intel.com> <70A7408C6E1BFB41B192A929744D8523968F8CC8@ALA-MBC.corp.ad.wrs.com> <20170329070150.GF18844@yliu-dev.sh.intel.com> <70A7408C6E1BFB41B192A929744D8523968FA875@ALA-MBC.corp.ad.wrs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70A7408C6E1BFB41B192A929744D8523968FA875@ALA-MBC.corp.ad.wrs.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH] vhost: change mbuf allocation logs to debug 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: Thu, 30 Mar 2017 01:51:57 -0000 On Wed, Mar 29, 2017 at 10:45:55PM +0000, Legacy, Allain wrote: > > -----Original Message----- > > From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com] > > Sent: Wednesday, March 29, 2017 3:02 AM > > <...> > > > > OTOH, it's still good to have RTE_LOG_ONCE. It explicitly tells you something > > is wrong, then you could dump those stats for more info. > > Has the implementation of something like RTE_LOG_ONCE been discussed before? No. It's just something comes to my mind after saw your patch. > Do you have a proposal on what you would find acceptable as an implementation that considers multiples threads, multiple devices, multiple logs per file, etc.? No, that would be way to complex. Something I thought of is quite simple (like what Linux kernel does): #define RTE_LOG_ONCE(...) do { \ static int warned; \ if (!warned) { \ RTE_LOG(...); \ warned = 1; \ } \ } while (0) And yes, I know it's far away from being perfect (and accurate, regarding to multiple devices and so on as you mentioned). Even though, I think it's much better than showing nothing when something goes wrong. --yliu