From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-f66.google.com (mail-vs1-f66.google.com [209.85.217.66]) by dpdk.org (Postfix) with ESMTP id C6F821B200 for ; Wed, 9 Jan 2019 10:38:20 +0100 (CET) Received: by mail-vs1-f66.google.com with SMTP id x28so4304825vsh.12 for ; Wed, 09 Jan 2019 01:38:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KR3LEUq5kTDaI7i4zFYq1sudijrt065Db3MMNLMKk5M=; b=hdZLn5x1qjzhhSKQzWIBPPe9Ong5+C2wl4Nd7NLhXF/jq+LIkq7myTIqUolJSGqyf9 e7lsAhh6oED9Nsod92jD3+s8FSgzFKmUjKJ6FEQtqjF0D5OxGq7dB08HqGGP6d7zVweN zrStnchHsYy6Vvlt9rcveG4iJvA+Iy7+OOTXuXU1tyFFF5gh4ih7nscSDr0uT5QaHEUv /D+8R3dTuSzloyvrrKnn8QC9EQXygyyb4y07R19Qb0VnW6yRkXUMQI/GtDML33G1tim2 EfkF/FBtxHfTqbLzIwCMRaxB7ibKJnsS9chrtWe8jvzwz6ZsHKX5hVbLQccrz46EL1Ib WE4A== X-Gm-Message-State: AJcUukf6r/v91PMays70joF2/v1ARRIavIZFmztdqx46QsXPKYuhSaNP n/LjCZFoZLA4tk/d4shr6fKSypMMkEAAeOHsxn+l8w== X-Google-Smtp-Source: ALg8bN5aJYF65PDHyifSlFvcD9obJ3EoFmfW8Y7xYy+nc7bYEq3g2P89w5+IBSW2OGTVi+0xZ1efhQ0pUedRq4g9/2I= X-Received: by 2002:a67:1b04:: with SMTP id b4mr2159109vsb.141.1547026700228; Wed, 09 Jan 2019 01:38:20 -0800 (PST) MIME-Version: 1.0 References: <20190109085426.39965-1-yskoh@mellanox.com> In-Reply-To: <20190109085426.39965-1-yskoh@mellanox.com> From: David Marchand Date: Wed, 9 Jan 2019 10:38:07 +0100 Message-ID: To: Yongseok Koh Cc: shahafs@mellanox.com, dev@dpdk.org, stable@dpdk.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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:38:21 -0000 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(). -- David Marchand