From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from proxy.6wind.com (host.76.145.23.62.rev.coltfrance.com [62.23.145.76]) by dpdk.org (Postfix) with ESMTP id D97551B399; Wed, 9 Jan 2019 10:52:05 +0100 (CET) Received: from core.dev.6wind.com (unknown [10.0.0.1]) by proxy.6wind.com (Postfix) with ESMTPS id 3261124ACD2; Wed, 9 Jan 2019 10:47:24 +0100 (CET) Received: from [10.16.0.195] (helo=6wind.com) by core.dev.6wind.com with smtp (Exim 4.84_2) (envelope-from ) id 1ghAWX-00056t-0y; Wed, 09 Jan 2019 10:51:46 +0100 Received: by 6wind.com (sSMTP sendmail emulation); Wed, 09 Jan 2019 10:52:05 +0100 Date: Wed, 9 Jan 2019 10:52:05 +0100 From: Olivier Matz To: David Marchand Cc: Yongseok Koh , shahafs@mellanox.com, dev@dpdk.org, stable@dpdk.org Message-ID: <20190109095205.us53xaocvokx4jog@glumotte.dev.6wind.com> References: <20190109085426.39965-1-yskoh@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH] net/mlx5: fix instruction hotspot on replenishing Rx buffer 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: Wed, 09 Jan 2019 09:52:06 -0000 On Wed, Jan 09, 2019 at 10:38:07AM +0100, David Marchand wrote: > On Wed, Jan 9, 2019 at 9:54 AM Yongseok Koh wrote: > > > On replenishing Rx buffers for vectorized Rx, mbuf->buf_addr isn't needed > > to be accessed as it is static and easily calculated from the mbuf address. > > Accessing the mbuf content causes unnecessary load stall and it is worsened > > on ARM. > > > > Fixes: 545b884b1da3 ("net/mlx5: fix buffer address posting in SSE Rx") > > Cc: stable@dpdk.org > > > > Signed-off-by: Yongseok Koh > > --- > > drivers/net/mlx5/mlx5_rxtx_vec.h | 8 ++++++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/net/mlx5/mlx5_rxtx_vec.h > > b/drivers/net/mlx5/mlx5_rxtx_vec.h > > index fda7004e2d..ced5547307 100644 > > --- a/drivers/net/mlx5/mlx5_rxtx_vec.h > > +++ b/drivers/net/mlx5/mlx5_rxtx_vec.h > > @@ -102,8 +102,12 @@ mlx5_rx_replenish_bulk_mbuf(struct mlx5_rxq_data > > *rxq, uint16_t n) > > return; > > } > > for (i = 0; i < n; ++i) { > > - wq[i].addr = rte_cpu_to_be_64((uintptr_t)elts[i]->buf_addr > > + > > - RTE_PKTMBUF_HEADROOM); > > + uintptr_t buf_addr = > > + (uintptr_t)elts[i] + sizeof(struct rte_mbuf) + > > + rte_pktmbuf_priv_size(rxq->mp) + > > RTE_PKTMBUF_HEADROOM; > > + > > + assert(buf_addr == (uintptr_t)elts[i]->buf_addr); > > + wq[i].addr = rte_cpu_to_be_64(buf_addr); > > /* If there's only one MR, no need to replace LKey in WQE. > > */ > > if (unlikely(mlx5_mr_btree_len(&rxq->mr_ctrl.cache_bh) > > > 1)) > > wq[i].lkey = mlx5_rx_mb2mr(rxq, elts[i]); > > -- > > 2.11.0 > > > > > How about having a macro / inline in the mbuf api to get this information > in a consistent/unique way ? > I can see we have this calculation at least in rte_pktmbuf_init() and > rte_pktmbuf_detach(). Agree. Maybe rte_mbuf_default_buf_addr(m) ? Side note, is the assert() correct in the patch? I'd say there's a difference of RTE_PKTMBUF_HEADROOM between the 2 values. Olivier