From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas@monjalon.net>
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com
 [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id DBF321CAC2
 for <dev@dpdk.org>; Mon, 14 May 2018 20:48:41 +0200 (CEST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailout.nyi.internal (Postfix) with ESMTP id 54A2B2235F;
 Mon, 14 May 2018 14:48:41 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute1.internal (MEProxy); Mon, 14 May 2018 14:48:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 cc:content-transfer-encoding:content-type:date:from:in-reply-to
 :message-id:mime-version:references:subject:to:x-me-sender
 :x-me-sender:x-sasl-enc; s=mesmtp; bh=8RFnwCD72fv7PxQsg+8wNgt561
 qsdX2MhKdsmh6/zJE=; b=iZ9HICCCX65gLNf0cQuKxWb5SyBUOH0ot3aDEWVro1
 Q4LH51lFt7HWaE8a5XeoUP68aAEAc9z5N+RVNc72JVRX2eZ5Cg23rjfb1JtEAO12
 wu/CUsXnt6tyuqqAZzcwSNhFsookCBJFuxY/d1tjeejQtMMYGqv/3nkXFxQyweeW
 E=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :date:from:in-reply-to:message-id:mime-version:references
 :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8RFnwC
 D72fv7PxQsg+8wNgt561qsdX2MhKdsmh6/zJE=; b=I43CQObtqjaujdNpD5aos/
 OewfhhNIBk/E0uPY3bp2DbSElXzSb8qTaH5ShSI5aedgSJNZqsqyzG9+IcS7trXj
 CTeMmtnL54Jp7l7sUeVsUC87bLVcay/1CkfH1LNNTTOd372zEdbxOymldR0KzsuH
 SFSJcoD9csqTJ0RCRtEt+ktznfWj4nkZOIqD1z0RJZ4qVctetXQ/xasSbH7cfU/8
 x+h0s2oUqUIEE6bEKThkrwery92m/r67cFoTJ6qN0Ue46BHVo1b+g3WYnTJuKhIs
 +9QNW99j2nq5z4kePUeAjySL67gn5apnDPLnxwm8ehu73aGHtNbXpdO2Dq4pOvtQ
 ==
X-ME-Sender: <xms:Cdr5WvTAtcmfDAq0pwBxSfAKttPQw93WFa70rW9NHxvyxbB6CsQU3A>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id 6E476E5088;
 Mon, 14 May 2018 14:48:40 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Anatoly Burakov <anatoly.burakov@intel.com>
Cc: dev@dpdk.org, Olivier Matz <olivier.matz@6wind.com>,
 konstantin.ananyev@intel.com, arybchenko@solarflare.com,
 shreyansh.jain@nxp.com
Date: Mon, 14 May 2018 20:48:39 +0200
Message-ID: <1848737.7LY3OboWmP@xps>
In-Reply-To: <014e66f8e34cb87fa126b7494ad644ef9ac68978.1526313945.git.anatoly.burakov@intel.com>
References: <014e66f8e34cb87fa126b7494ad644ef9ac68978.1526313945.git.anatoly.burakov@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [PATCH] mempool: fix virt address mempool population
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://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: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 14 May 2018 18:48:42 -0000

14/05/2018 18:06, Anatoly Burakov:
> Currently, populate_virt will check if mempool is already populated.
> This will cause inability to reserve multi-chunk mempools if
> contiguous memory is not a hard requirement, because if allocating
> all-contiguous memory fails, mempool will retry with virtual addresses
> and will call populate_virt. It seems that the original code never
> anticipated more than one non-physically contiguous area.
> 
> Fix it by removing the check in populate virt. populate_anon() function
> calls populate_virt() also, and it can be reasonably inferred that it is
> expecting that virtual area is not already populated. Even though a
> similar check is already in place there, also add the check that was
> part of populate_virt() just in case.
> 
> Fixes: aab4f62d6c1c ("mempool: support no hugepage mode")

If it is really the root cause, you need to add Cc: stable@dpdk.org.

> Cc: olivier.matz@6wind.com
> 
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>

This patch looks sensible. It will wait some review,
so it is a candidate for -rc4.