From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail-wr0-f177.google.com (mail-wr0-f177.google.com
[209.85.128.177]) by dpdk.org (Postfix) with ESMTP id 08038374F
for <dev@dpdk.org>; Mon, 3 Jul 2017 18:37:17 +0200 (CEST)
Received: by mail-wr0-f177.google.com with SMTP id c11so237258696wrc.3
for <dev@dpdk.org>; Mon, 03 Jul 2017 09:37:17 -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:in-reply-to:references
:mime-version:content-transfer-encoding;
bh=3rMevIOMYYBhfgem5WoB/GQKKuUFwmUkWMzFZyoE6lQ=;
b=jYt4xHimWb/L8eOZFDnfMWy+61k+kP9w7uc8fFqxljni0qMdR67cz8LH6yA4EzRvVf
SawROk6JxlK6KPQSL3cjnHNQ81HeO5kfbzjJw3H6IX6dRdJ55Cgk78BUdnz4bWX41h5f
DN5R4rAqYxq9e983TpfUGhsyDynMOWinZszEFRkmIycNk8FDZ09JY5x/9SVgzSv7hQ6+
5bbscfQcMF3t7AuPdXb9ZGKgtWeBBgrL9qghK7zLklXZWemItDcjr23eD5erwsVPpsom
taATz92Xf36ITQXKlOxZpq9bhl2hU/Udnu07mXBURYhkeLapYO666oyTkLmLWMe56bkU
7WAg==
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:in-reply-to
:references:mime-version:content-transfer-encoding;
bh=3rMevIOMYYBhfgem5WoB/GQKKuUFwmUkWMzFZyoE6lQ=;
b=qiMzJ8CZB9OweGTyG27gjo71zKrj+PX2L8O12OYk2plksrA7/wCDBqN+LintXv7f2G
aHWYAScNiP+6A+uSqjk0m9oUgCvRLjbxkcvlKEsdmOYPlGSowwucRDJgfseV4bmuLpf/
iVx8treHtbrSYihK/ghoDjW+rHlBc9BP7IShNuWutj/5Irq3W7hI1y/Cu10zfdTXNX8W
cLkHASr7Sh/wwTX3FvnZ7Hj1QffLYF5pmoQ9sxXDvP20roUjbIaYmdGV/PDAEOWoafnT
WobxyYtRpdXrsjIj+5DZgsTI84MORKSWpqeK73ugjweGhIMR+tx518tn+9lItNyHH1En
PGgg==
X-Gm-Message-State: AKS2vOwMK29AtFt7c23upo/F2eI6A+vyjMLREyroTm2NiJ8PAPalxr1Y
zZEYRCpSVQKrdONA
X-Received: by 10.223.133.99 with SMTP id 90mr35264366wrh.44.1499099837691;
Mon, 03 Jul 2017 09:37:17 -0700 (PDT)
Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr.
[2a01:cb0c:3c6:5100:226:b0ff:feed:2fc])
by smtp.gmail.com with ESMTPSA id p87sm32102530wma.2.2017.07.03.09.37.17
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Mon, 03 Jul 2017 09:37:17 -0700 (PDT)
Date: Mon, 3 Jul 2017 18:37:15 +0200
From: Olivier Matz <olivier.matz@6wind.com>
To: Santosh Shukla <santosh.shukla@caviumnetworks.com>
Cc: dev@dpdk.org, thomas@monjalon.net, hemant.agrawal@nxp.com,
jerin.jacob@caviumnetworks.com, bruce.richardson@intel.com
Message-ID: <20170703183715.3b1c8ff6@platinum>
In-Reply-To: <20170621173248.1313-3-santosh.shukla@caviumnetworks.com>
References: <20170621173248.1313-1-santosh.shukla@caviumnetworks.com>
<20170621173248.1313-3-santosh.shukla@caviumnetworks.com>
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH 2/4] mempool: detect physical contiguous
object in pool
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jul 2017 16:37:18 -0000
On Wed, 21 Jun 2017 17:32:46 +0000, Santosh Shukla <santosh.shukla@caviumnetworks.com> wrote:
> HW mempool blocks may need physical contiguous obj in a pool.
This should be clarified: the memory area containing all the
objects must be physically contiguous, right?
> Introducing MEMPOOL_F_POOL_CONTIG flag for such use-case. The flag
> useful to detect whether all buffer fits within a hugepage or not. If
> not then return -ENOSPC. This way, we make sure that all object within a
> pool is contiguous.
>
> Signed-off-by: Santosh Shukla <santosh.shukla@caviumnetworks.com>
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
> lib/librte_mempool/rte_mempool.c | 8 ++++++++
> lib/librte_mempool/rte_mempool.h | 1 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
> index 045baef45..7dec2f51d 100644
> --- a/lib/librte_mempool/rte_mempool.c
> +++ b/lib/librte_mempool/rte_mempool.c
> @@ -368,6 +368,14 @@ rte_mempool_populate_phys(struct rte_mempool *mp, char *vaddr,
>
> total_elt_sz = mp->header_size + mp->elt_size + mp->trailer_size;
>
> + /* Detect nb_mbuf fit in hugepage */
> + if (mp->flags & MEMPOOL_F_POOL_CONTIG) {
> + if (len < total_elt_sz * mp->size) {
> + RTE_LOG(ERR, MEMPOOL, "nb_mbufs not fitting in one hugepage,..exit\n");
> + return -ENOSPC;
> + }
> + }
> +
We should not reference mbuf, we are in mempool code, dealing with
any kind of object.
Also, len is not necessarily the size of a hugepage, but the size of the
physical area passed to te_mempool_populate_phys().
> memhdr = rte_zmalloc("MEMPOOL_MEMHDR", sizeof(*memhdr), 0);
> if (memhdr == NULL)
> return -ENOMEM;
> diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
> index c3cdc77e4..fd8722e69 100644
> --- a/lib/librte_mempool/rte_mempool.h
> +++ b/lib/librte_mempool/rte_mempool.h
> @@ -266,6 +266,7 @@ struct rte_mempool {
> #define MEMPOOL_F_SC_GET 0x0008 /**< Default get is "single-consumer".*/
> #define MEMPOOL_F_POOL_CREATED 0x0010 /**< Internal: pool is created. */
> #define MEMPOOL_F_NO_PHYS_CONTIG 0x0020 /**< Don't need physically contiguous objs. */
> +#define MEMPOOL_F_POOL_CONTIG 0x0040 /**< Detect physcially contiguous objs */
We must highlight here that it's a capability flag.
Following my other comments on the first patch, this define should be
renamed in something else. I suggest:
#define RTE_MEMPOOL_CAPA_PHYS_CONTIG 0x0001
The description should be longer and more accurate.
I'm also a bit puzzled because this is more a limitation than a
capability.
>
> /**
> * @internal When debug is enabled, store some statistics.