From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id B92C9101B for ; Tue, 28 Mar 2017 08:50:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1490683855; x=1522219855; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=8EAAxpQmuusnNcy88vvjHjmeG8Q+wVNPkwzC1XvftaI=; b=GisjGuQ3S45rIfHjPj3KkXUWE+9FLjDZgeY15OhuasHjvlXEMsz3JViP 6wsPtrWyXQOj5n4qH6sPc3HIlrnEew==; Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2017 23:50:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,235,1486454400"; d="scan'208";a="81741686" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by fmsmga006.fm.intel.com with ESMTP; 27 Mar 2017 23:50:52 -0700 Date: Tue, 28 Mar 2017 14:48:41 +0800 From: Yuanhan Liu To: Allain Legacy Cc: mtetsuyah@gmail.com, maxime.coquelin@redhat.com, dev@dpdk.org, matt.peters@windriver.com, Thomas Monjalon Message-ID: <20170328064841.GZ18844@yliu-dev.sh.intel.com> References: <20170327162930.54281-1-allain.legacy@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170327162930.54281-1-allain.legacy@windriver.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: Tue, 28 Mar 2017 06:50:56 -0000 On Mon, Mar 27, 2017 at 12:29:30PM -0400, Allain Legacy wrote: > From: Matt Peters > > The current packet buffer alloc failures of the vhost dequeue operations > can flood the log system with error logs due to logging a runtime error > condition within the data path. I agree that we should avoid flood. But somehow I think it's valueable to print such message. It could simply mean you don't have enough mbuf created, or, unlikely, mbuf leak happended. > In order to prevent this condition, but > still enable debugging, the logs are being changed to debug logs to ensure > they are not emitted unless the CONFIG_RTE_LIBRTE_VHOST_DEBUG option is > enabled. That basically means you will never see them in real life. I'm suggesting to add a new log API, RTE_LOG_ONCE. Sounds good? --yliu > > Signed-off-by: Matt Peters > Signed-off-by: Allain Legacy > --- > lib/librte_vhost/virtio_net.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c > index 337470d64..850b56082 100644 > --- a/lib/librte_vhost/virtio_net.c > +++ b/lib/librte_vhost/virtio_net.c > @@ -901,7 +901,7 @@ copy_desc_to_mbuf(struct virtio_net *dev, struct vring_desc *descs, > if (mbuf_avail == 0) { > cur = rte_pktmbuf_alloc(mbuf_pool); > if (unlikely(cur == NULL)) { > - RTE_LOG(ERR, VHOST_DATA, "Failed to " > + LOG_DEBUG(VHOST_DATA, "Failed to " > "allocate memory for mbuf.\n"); > return -1; > } > @@ -1129,7 +1129,7 @@ rte_vhost_dequeue_burst(int vid, uint16_t queue_id, > > pkts[i] = rte_pktmbuf_alloc(mbuf_pool); > if (unlikely(pkts[i] == NULL)) { > - RTE_LOG(ERR, VHOST_DATA, > + LOG_DEBUG(VHOST_DATA, > "Failed to allocate memory for mbuf.\n"); > break; > } > -- > 2.12.1