From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com [74.125.82.68]) by dpdk.org (Postfix) with ESMTP id 3C4EF1B65B for ; Mon, 23 Oct 2017 17:24:22 +0200 (CEST) Received: by mail-wm0-f68.google.com with SMTP id m72so10299640wmc.1 for ; Mon, 23 Oct 2017 08:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=i08n/4PVt2wPLGzIHIWIMEEXf9QiqslZLq8Fv41LRM0=; b=lRvE/i4wlcVM2SCswE6SAuInGVQH8iFYjXi5HH/LNDxuGR4BGnKet5c4zpxaqw3GWP Ei5U/XF92VMk16UXx/4VNxFWr5/Zf1CRZ36kVHhLYtcsuLGdua03eUaJCucjscSC34So QzrNTC8Vlt4sy1WmGLG+h+Xn9QXVyenNBpKyRwu3HXqfPIuohS6w79Qebh/9vE1t+nNT lyaTp7jRhNGO5gqMPxRoHZ4kBscrdCxaKUd6Qzm5+bSd2nY5BnxLMjq38WWZDWR9Yggr maqjwY03S3Aezv8vJeEM5KTsQK61n3VZgBskUeWvXm3wqSsJuwbX5O1szY85jiHhOBKF cTng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=i08n/4PVt2wPLGzIHIWIMEEXf9QiqslZLq8Fv41LRM0=; b=Jd6+mqm5MZrj422JVz7MqZ7kRC4pNNe4HRiPU2bpNp+OsxmRV/bNuvy79X2056UvNr 8FylMRw7SImSc6ocQ3rOdDYyAk2QfKZw1f3mwYDzsLpnXj7au+cWprYt8hOY9xdOkzel lpdljpO2caOSKzjbzA0S3/XXLemzcV3mWP1ksu3ERHp3x3aB4vWJV+gEHodAwj/bkJdH YtWSmW9Jhg1qTXOfKO8STSdK2oJc+G09ousT3qP7NePGXgRLc/g0VQyOTEVRYY7Lofp7 aw73DCakTCa9C5/QSs5j8GF3XFGYBkjM4m1xxyqEYA/r2ZnSZUrXdmc4ituY3A3RDSXG wHJw== X-Gm-Message-State: AMCzsaVjBSf28W2lTjvgJxhq4v/Tipi/cM2rTbIoivlwNY/BYS61Z1Yr 29gD4s+yWS5aYF/9lV6Xsia0 X-Google-Smtp-Source: ABhQp+T1Jl8fRhFnjUD7w+16q4bDQYYN8ENoP/jgCCMY+Vit2bx1NAYFnVAiJRvu6mOaLsgLZ8QKYQ== X-Received: by 10.28.229.149 with SMTP id c143mr5101209wmh.156.1508772261867; Mon, 23 Oct 2017 08:24:21 -0700 (PDT) Received: from laranjeiro-vm (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id v5sm5486651wrf.29.2017.10.23.08.24.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 23 Oct 2017 08:24:21 -0700 (PDT) From: "=?iso-8859-1?Q?N=E9lio?= Laranjeiro" X-Google-Original-From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro Date: Mon, 23 Oct 2017 17:24:16 +0200 To: Ophir Munk Cc: Adrien Mazarguil , dev@dpdk.org, Thomas Monjalon , Olga Shern , Matan Azrad Message-ID: <20171023152416.wmbb474qs4mkhlwd@laranjeiro-vm> References: <1508752838-30408-1-git-send-email-ophirmu@mellanox.com> <1508768520-4810-1-git-send-email-ophirmu@mellanox.com> <1508768520-4810-4-git-send-email-ophirmu@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1508768520-4810-4-git-send-email-ophirmu@mellanox.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v2 3/7] net/mlx4: save lkey in big-endian format 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: Mon, 23 Oct 2017 15:24:22 -0000 Hi Ophir, Some small comments, please see bellow On Mon, Oct 23, 2017 at 02:21:56PM +0000, Ophir Munk wrote: > mlx4 NIC is using lkey in big endian format. Save lkey in this format > in order to avoid conversions during Tx fast path > > Signed-off-by: Ophir Munk > --- > drivers/net/mlx4/mlx4_rxtx.c | 16 +++++++--------- > drivers/net/mlx4/mlx4_rxtx.h | 14 ++++++++------ > 2 files changed, 15 insertions(+), 15 deletions(-) > > diff --git a/drivers/net/mlx4/mlx4_rxtx.c b/drivers/net/mlx4/mlx4_rxtx.c > index ae37f9b..4a77be8 100644 > --- a/drivers/net/mlx4/mlx4_rxtx.c > +++ b/drivers/net/mlx4/mlx4_rxtx.c > @@ -233,9 +233,9 @@ mlx4_txq_complete(struct txq *txq) > * Index in memory pool (MP) where to add memory region (MR) > * > * @return > - * Added mr->lkey on success, (uint32_t)-1 on failure. > + * Added mr->lkey (rte_be32_t) on success, (uint32_t)-1 on failure. This comment is strange, it always returns an rte_be32_t no matter what. > */ > -uint32_t mlx4_txq_add_mr(struct txq *txq, struct rte_mempool *mp, uint32_t i) > +rte_be32_t mlx4_txq_add_mr(struct txq *txq, struct rte_mempool *mp, uint32_t i) > { > struct ibv_mr *mr; > > @@ -260,9 +260,9 @@ uint32_t mlx4_txq_add_mr(struct txq *txq, struct rte_mempool *mp, uint32_t i) > /* Store the new entry. */ > txq->mp2mr[i].mp = mp; > txq->mp2mr[i].mr = mr; > - txq->mp2mr[i].lkey = mr->lkey; > + txq->mp2mr[i].lkey = rte_cpu_to_be_32(mr->lkey); > DEBUG("%p: new MR lkey for MP \"%s\" (%p): 0x%08" PRIu32, > - (void *)txq, mp->name, (void *)mp, txq->mp2mr[i].lkey); > + (void *)txq, mp->name, (void *)mp, mr->lkey); > return txq->mp2mr[i].lkey; > } > > @@ -289,7 +289,6 @@ mlx4_post_send(struct txq *txq, struct rte_mbuf *pkt) > uint16_t flags16[2]; > } srcrb; > uint32_t head_idx = sq->head & sq->txbb_cnt_mask; > - uint32_t lkey; > uintptr_t addr; > uint32_t owner_opcode = MLX4_OPCODE_SEND; > uint32_t byte_count; > @@ -323,10 +322,10 @@ mlx4_post_send(struct txq *txq, struct rte_mbuf *pkt) > if (unlikely(dseg >= (struct mlx4_wqe_data_seg *)sq->eob)) > dseg = (struct mlx4_wqe_data_seg *)sq->buf; > dseg->addr = rte_cpu_to_be_64(addr); > - /* Memory region key for this memory pool. */ > - lkey = mlx4_txq_mp2mr(txq, mlx4_txq_mb2mp(buf)); > + /* Memory region key (big endian) for this memory pool. */ > + dseg->lkey = mlx4_txq_mp2mr(txq, mlx4_txq_mb2mp(buf)); Is not the comment redundant with the return type of the function? > #ifndef NDEBUG > - if (unlikely(lkey == (uint32_t)-1)) { > + if (unlikely(dseg->lkey == rte_cpu_to_be_32((uint32_t)-1))) { ((uint32_t)-1) == ((rte_be32_t)-1) like (uin32t_t)0 == (rte_be32_t)0. Why do you need this extra conversion? > /* MR does not exist. */ > DEBUG("%p: unable to get MP <-> MR association", > (void *)txq); > @@ -341,7 +340,6 @@ mlx4_post_send(struct txq *txq, struct rte_mbuf *pkt) > return -EFAULT; > } > #endif /* NDEBUG */ > - dseg->lkey = rte_cpu_to_be_32(lkey); > if (likely(buf->data_len)) { > byte_count = rte_cpu_to_be_32(buf->data_len); > } else { > diff --git a/drivers/net/mlx4/mlx4_rxtx.h b/drivers/net/mlx4/mlx4_rxtx.h > index 719ef45..b1e8ac4 100644 > --- a/drivers/net/mlx4/mlx4_rxtx.h > +++ b/drivers/net/mlx4/mlx4_rxtx.h > @@ -135,7 +135,7 @@ struct txq { > struct { > const struct rte_mempool *mp; /**< Cached memory pool. */ > struct ibv_mr *mr; /**< Memory region (for mp). */ > - uint32_t lkey; /**< mr->lkey copy. */ > + rte_be32_t lkey; /**< mr->lkey copy. (big endian) */ The "big endian" in the comment is redundant. > } mp2mr[MLX4_PMD_TX_MP_CACHE]; /**< MP to MR translation table. */ > struct priv *priv; /**< Back pointer to private data. */ > unsigned int socket; /**< CPU socket ID for allocations. */ > @@ -169,7 +169,7 @@ uint16_t mlx4_tx_burst_removed(void *dpdk_txq, struct rte_mbuf **pkts, > uint16_t pkts_n); > uint16_t mlx4_rx_burst_removed(void *dpdk_rxq, struct rte_mbuf **pkts, > uint16_t pkts_n); > -uint32_t mlx4_txq_add_mr(struct txq *txq, struct rte_mempool *mp, > +rte_be32_t mlx4_txq_add_mr(struct txq *txq, struct rte_mempool *mp, > unsigned int i); > > /* mlx4_txq.c */ > @@ -207,9 +207,9 @@ mlx4_txq_mb2mp(struct rte_mbuf *buf) > * Memory pool for which a memory region lkey must be returned. > * > * @return > - * mr->lkey on success, (uint32_t)-1 on failure. > + * mr->lkey (rte_be32_t) on success, (uint32_t)-1 on failure. The comment is also strange, the return type does not change in the mean time. > */ > -static __rte_always_inline uint32_t > +static __rte_always_inline rte_be32_t > mlx4_txq_mp2mr(struct txq *txq, struct rte_mempool *mp) > { > unsigned int i; > @@ -220,8 +220,10 @@ mlx4_txq_mp2mr(struct txq *txq, struct rte_mempool *mp) > break; > } > if (txq->mp2mr[i].mp == mp) { > - assert(txq->mp2mr[i].lkey != (uint32_t)-1); > - assert(txq->mp2mr[i].mr->lkey == txq->mp2mr[i].lkey); > + assert(txq->mp2mr[i].lkey != > + rte_cpu_to_be_32((uint32_t)-1)); Thanks, -- Nélio Laranjeiro 6WIND