From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 39F49201 for ; Mon, 4 Apr 2016 21:55:20 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP; 04 Apr 2016 12:55:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,441,1455004800"; d="scan'208";a="938093608" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.191]) by fmsmga001.fm.intel.com with ESMTP; 04 Apr 2016 12:55:15 -0700 Date: Tue, 5 Apr 2016 03:56:39 +0800 From: Yuanhan Liu To: Thomas Monjalon Cc: Keith Wiles , dev@dpdk.org, huawei.xie@intel.com, adrien.mazarguil@6wind.com Message-ID: <20160404195639.GJ3080@yliu-dev.sh.intel.com> References: <1459538419-81284-1-git-send-email-keith.wiles@intel.com> <22459074.ccNYgpjxy1@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22459074.ccNYgpjxy1@xps13> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH] gcc compiler option -Og warnings fix X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:55:20 -0000 On Mon, Apr 04, 2016 at 04:10:54PM +0200, Thomas Monjalon wrote: > --- a/lib/librte_vhost/vhost_rxtx.c > +++ b/lib/librte_vhost/vhost_rxtx.c > @@ -147,8 +147,10 @@ copy_mbuf_to_desc(struct virtio_net *dev, struct vhost_virtqueue *vq, > struct virtio_net_hdr_mrg_rxbuf virtio_hdr = {{0, 0, 0, 0, 0, 0}, 0}; > > desc = &vq->desc[desc_idx]; > - if (unlikely(desc->len < vq->vhost_hlen)) > + if (unlikely(desc->len < vq->vhost_hlen)) { > + *copied = 0; > return -1; > + } > > > err = copy_mbuf_to_desc(dev, vq, pkts[i], desc_idx, &copied); > > @@ -531,7 +531,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id, > > { > > struct vhost_virtqueue *vq; > > uint32_t pkt_idx = 0, nr_used = 0; > > - uint16_t start, end; > > + uint16_t start = 0, end = 0; > > I don't understand this one because the variables are not used if > reserve_avail_buf_mergeable fails. > I don't see any smart workaround. > Huawei, Yuanhan, can we expect a little slowdown with this change? I agree with you that the compiler seems buggy here, I'm okay with the fix though: it should not introduce slowdown, IMO. However, I'd ask the opinion from Huawei: he knows this better than me. --yliu