From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id E5D8F556D for ; Mon, 3 Nov 2014 13:38:21 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 03 Nov 2014 04:47:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="410347910" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.220.79]) by FMSMGA003.fm.intel.com with SMTP; 03 Nov 2014 04:39:09 -0800 Received: by (sSMTP sendmail emulation); Mon, 03 Nov 2014 12:47:32 +0025 Date: Mon, 3 Nov 2014 12:47:32 +0000 From: Bruce Richardson To: David Marchand Message-ID: <20141103124732.GB4840@bricha3-MOBL3> References: <1415013076-30314-1-git-send-email-bruce.richardson@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] ixgbe: fix icc issue with mbuf initializer 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, 03 Nov 2014 12:38:22 -0000 On Mon, Nov 03, 2014 at 01:31:10PM +0100, David Marchand wrote: > Hello Bruce, > > On Mon, Nov 3, 2014 at 12:11 PM, Bruce Richardson < > bruce.richardson@intel.com> wrote: > > > diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c > > b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c > > index e813e43..b57c588 100644 > > --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c > > +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c > > @@ -730,16 +730,15 @@ static struct ixgbe_txq_ops vec_txq_ops = { > > int > > ixgbe_rxq_vec_setup(struct igb_rx_queue *rxq) > > { > > - struct rte_mbuf mb_def = { > > - .nb_segs = 1, > > - .data_off = RTE_PKTMBUF_HEADROOM, > > -#ifdef RTE_MBUF_REFCNT > > - { .refcnt = 1, } > > -#endif > > - }; > > + struct rte_mbuf mb_def = { .buf_addr = 0 }; /* zeroed mbuf */ > > > > + mb_def.nb_segs = 1; > > + mb_def.data_off = RTE_PKTMBUF_HEADROOM; > > mb_def.buf_len = rxq->mb_pool->elt_size - sizeof(struct rte_mbuf); > > mb_def.port = rxq->port_id; > > +#ifdef RTE_MBUF_REFCNT > > + mb_def.refcnt = 1; > > +#endif > > rxq->mbuf_initializer = *((uint64_t *)&mb_def.rearm_data); > > return 0; > > } > > > > I would expect we use rte_mbuf_refcnt_set / rte_mbuf_refcnt_read to access > this "refcnt" field. > This api handles both RTE_MBUF_REFCNT_ATOMIC and ! RTE_MBUF_REFCNT_ATOMIC > configs. > But I suppose this is fine at init time (since the union will initialize > properly the field). It's a good point, I'll update patch to use the appropriate macro which will clean up the code a bit. /Bruce > > By the way, why do we have this RTE_MBUF_REFCNT_ATOMIC option ? > From my point of view, there is not much use of a refcnt that is not atomic > :-). > > > -- > David Marchand