From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dmarchan@redhat.com>
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 <dev@dpdk.org>; Wed,  9 Jan 2019 10:38:20 +0100 (CET)
Received: by mail-vs1-f66.google.com with SMTP id x28so4304825vsh.12
 for <dev@dpdk.org>; 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 <david.marchand@redhat.com>
Date: Wed, 9 Jan 2019 10:38:07 +0100
Message-ID: <CAJFAV8x+WBbei_HwQeGMdb+YZw8YSEWgP4uVp0Nihewc=myEaw@mail.gmail.com>
To: Yongseok Koh <yskoh@mellanox.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2019 09:38:21 -0000

On Wed, Jan 9, 2019 at 9:54 AM Yongseok Koh <yskoh@mellanox.com> 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 <yskoh@mellanox.com>
> ---
>  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