From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com [209.85.128.170]) by dpdk.org (Postfix) with ESMTP id A9FD02BB4 for ; Mon, 3 Jul 2017 16:06:14 +0200 (CEST) Received: by mail-wr0-f170.google.com with SMTP id 77so235016407wrb.1 for ; Mon, 03 Jul 2017 07:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=U56RpTzmgYrFSZEIuJYqmGi0Ov2Yvy543lF8u8AaiaU=; b=xVGFbSuXfnMQ+FKreF+I9YNFHSWaJa+WNLdN6EQXskOjQHM/M3XjEOK3NbbCL99r/C 1MjNbPC0ta/2ExXWQGB2/mY0WMa2zsS7J43Yzdr8V0W+Fe18Uh3o22y1zhEhCtLnNGjT D0C6hyDew2d7YkVdcpEOQespsaFmPaFoYTmYEKnA8YoMdEhNlC8rcuQ87k1ks1B0ztRc fGHNFp6RLIMypxJPn79je9yLARCAqOf0NVAA2e2x9sxnbtt0A4GpA3VWgzdMP1nRRVxZ gTOdNW2CUNbA1H7xuxEN4gHrEGWyNRoL60tfox69XJNzAtQopUF+jK4kb59PbPzb24X2 t8dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=U56RpTzmgYrFSZEIuJYqmGi0Ov2Yvy543lF8u8AaiaU=; b=T+d0028xDNwhA0Z5Wz4bMGHBT+IrpxrY3nwsiwjQBRAD+l2EHv/iac8u4RtPEz9/Ws QefHRdlMCj06h9KpWuw5LJOLEUsuKPyOXr9V9pys7zbIrBn3IhORcVQ0vOV1jrE52uyP +JibJo+Xni13lEKUDg+jECctRgIuAbnQRpR2/0M7SaBzIgWIs2imdTiEnB3uoreO29zY +b305rKdGiIrbYVzatqXzAOL6PKM635rMR2J+Z8Ed+lEXuTjjgr4PR6IoyOPWiGJoI09 LwYOf4zwCy07kZrRZTxX5an4ajYux8DDkfl2RmlDfqIlwUX/yMk5DakIl/s+K2/+jrhb yJRg== X-Gm-Message-State: AKS2vOwcvn7QMyTauCUcUxNOmGiaIMsxP6QJbtu+42KDzENe3WSGQep0 HsrEpVjBp6wCEbrA X-Received: by 10.223.164.156 with SMTP id g28mr35247841wrb.105.1499090774194; Mon, 03 Jul 2017 07:06:14 -0700 (PDT) Received: from autoinstall.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id l6sm20689150wmg.31.2017.07.03.07.06.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 07:06:13 -0700 (PDT) Date: Mon, 3 Jul 2017 16:06:05 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Yongseok Koh Cc: ferruh.yigit@intel.com, dev@dpdk.org, adrien.mazarguil@6wind.com Message-ID: <20170703140605.GE18305@autoinstall.dev.6wind.com> References: <20170628230403.10142-1-yskoh@mellanox.com> <1342e608a5a7c45b7af17e9228d6ce643e7ae40e.1498850005.git.yskoh@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1342e608a5a7c45b7af17e9228d6ce643e7ae40e.1498850005.git.yskoh@mellanox.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v2 3/5] net/mlx5: use buffer address for LKEY search 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, 03 Jul 2017 14:06:14 -0000 On Fri, Jun 30, 2017 at 12:23:31PM -0700, Yongseok Koh wrote: > When searching LKEY, if search key is mempool pointer, the 2nd cacheline > has to be accessed and it even requires to check whether a buffer is > indirect per every search. Instead, using address for search key can reduce > cycles taken. And caching the last hit entry is beneficial as well. > > Signed-off-by: Yongseok Koh > --- > drivers/net/mlx5/mlx5_mr.c | 17 ++++++++++++++--- > drivers/net/mlx5/mlx5_rxtx.c | 39 +++++++++++++++++++++------------------ > drivers/net/mlx5/mlx5_rxtx.h | 4 +++- > drivers/net/mlx5/mlx5_txq.c | 3 +-- > 4 files changed, 39 insertions(+), 24 deletions(-) > > diff --git a/drivers/net/mlx5/mlx5_mr.c b/drivers/net/mlx5/mlx5_mr.c > index 0a3638460..287335179 100644 > --- a/drivers/net/mlx5/mlx5_mr.c > +++ b/drivers/net/mlx5/mlx5_mr.c > @@ -265,18 +266,28 @@ txq_mp2mr_iter(struct rte_mempool *mp, void *arg) > struct txq_mp2mr_mbuf_check_data data = { > .ret = 0, > }; > + uintptr_t start; > + uintptr_t end; > unsigned int i; > > /* Register mempool only if the first element looks like a mbuf. */ > if (rte_mempool_obj_iter(mp, txq_mp2mr_mbuf_check, &data) == 0 || > data.ret == -1) > return; > + if (mlx5_check_mempool(mp, &start, &end) != 0) { > + ERROR("mempool %p: not virtually contiguous", > + (void *)mp); > + return; > + } > for (i = 0; (i != RTE_DIM(txq_ctrl->txq.mp2mr)); ++i) { > - if (unlikely(txq_ctrl->txq.mp2mr[i].mp == NULL)) { > + struct ibv_mr *mr = txq_ctrl->txq.mp2mr[i].mr; > + > + if (unlikely(mr == NULL)) { > /* Unknown MP, add a new MR for it. */ > break; > } > - if (txq_ctrl->txq.mp2mr[i].mp == mp) > + if (start >= (uintptr_t)mr->addr && > + end <= (uintptr_t)mr->addr + mr->length) > return; > } > txq_mp2mr_reg(&txq_ctrl->txq, mp, i); if (start >= (uintptr_t)mr->addr && end <= (uintptr_t)mr->addr + mr->length) Is this expected to have a memory region bigger than the memory pool space? I mean I was expecting to see strict equality in the addresses. Regards, -- Nélio Laranjeiro 6WIND