From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7AC97CA9EAE for ; Tue, 29 Oct 2019 17:20:23 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 10A722067D for ; Tue, 29 Oct 2019 17:20:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=6wind.com header.i=@6wind.com header.b="BpNsoMbO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 10A722067D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=6wind.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 641531BF6B; Tue, 29 Oct 2019 18:20:22 +0100 (CET) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id C6E3F1BF69 for ; Tue, 29 Oct 2019 18:20:20 +0100 (CET) Received: by mail-wr1-f68.google.com with SMTP id o28so14546421wro.7 for ; Tue, 29 Oct 2019 10:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=fS10KKq0yImBgNIFdUEPnaNtna60Rkc/eFUYW8PzhSw=; b=BpNsoMbOE4jZRweMrxv8VMzx1gcZ6eGKL1beORqYKLgi0jOtIk16w6GQ7YRheAsCrU keBbzJbZRD/Ff0vwFWqz8hI3bUpd0iw4ATkNwlnonYHaZoBcD+v9X9rI/wZA4lKbE0D7 dFqEFjS4OJJuu6VrhcVt9P8y/R1dtyB7OHb4YaIF9dXGJsy8w6QJ5Drql4iMTGiGSrOY O0lFd0x1xgWthyD1ld5w86Y/obbr03+7beKDltLrVpQEOnk5tmVu160QE0e70R+hb3f6 QFhq0FbAiKS0o+tpkHW94rntGElfJumcyqytxGSiowvFHUKDYdK9JT6z94UfQsANqgtx QS/Q== 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:in-reply-to:user-agent; bh=fS10KKq0yImBgNIFdUEPnaNtna60Rkc/eFUYW8PzhSw=; b=RUeru8XjqRONB+ymaMF1d9Fe2XzIqeIaHTY5NbaHzOeoKUr3p9yGz70QraYChV2vDr yAUNRhywDfibwxVL0SCpvv2p9QPheGhUjYPHTsu/IWt8v0JTxBBaGqfiG+HvICaI2osY zIp00UguIRMVYZnieJ7QOuDS1hVhUu6Pn/QaMa6yam57jvJ7VjFFu/v62RL0+PhXmZew 5W0Go7nXU7zmvpscm61EyxR7U8BY0PHYalXVa7GYqQA6QcJR5rLFielTYa18DbaMd7zu P7j7eG0E/aB2kF+zlpet62o0l1kaixjuIga5T+1/AId7AjZR0WqZjrpG/XvwhyqwLq7H G2YA== X-Gm-Message-State: APjAAAWI1/BpfQwgtQ1mQ0fVi0imLDMZsurEjKdjfNWRLjngx3HyBhUC ZMcuRsbe0bdVyGx8VhLH5D+/Lw== X-Google-Smtp-Source: APXvYqyr1ftvbsTQ4NPCEtf0IUfAVhzrp0B1p5OurfZuPeOWtPXi9DXXsWJ3eglw37fu57NQmI69UQ== X-Received: by 2002:adf:ea50:: with SMTP id j16mr20257023wrn.295.1572369620520; Tue, 29 Oct 2019 10:20:20 -0700 (PDT) Received: from 6wind.com (2a01cb0c0005a6000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id 37sm26221446wrc.96.2019.10.29.10.20.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Oct 2019 10:20:19 -0700 (PDT) Date: Tue, 29 Oct 2019 18:20:18 +0100 From: Olivier Matz To: Andrew Rybchenko Cc: dev@dpdk.org, Anatoly Burakov , Ferruh Yigit , "Giridharan, Ganesan" , Jerin Jacob Kollanukkaran , Kiran Kumar Kokkilagadda , Stephen Hemminger , Thomas Monjalon , Vamsi Krishna Attunuru Message-ID: <20191029172018.wvz57dbuhyy4bd4k@platinum> References: <20190719133845.32432-1-olivier.matz@6wind.com> <20191028140122.9592-1-olivier.matz@6wind.com> <20191028140122.9592-4-olivier.matz@6wind.com> <24990d86-4ef8-4dce-113c-b824fe55e3f5@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24990d86-4ef8-4dce-113c-b824fe55e3f5@solarflare.com> User-Agent: NeoMutt/20180716 Subject: Re: [dpdk-dev] [PATCH 3/5] mempool: remove optimistic IOVA-contiguous allocation 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Oct 29, 2019 at 01:25:10PM +0300, Andrew Rybchenko wrote: > On 10/28/19 5:01 PM, Olivier Matz wrote: > > The previous commit reduced the amount of required memory when > > populating the mempool with non iova-contiguous memory. > > > > Since there is no big advantage to have a fully iova-contiguous mempool > > if it is not explicitly asked, remove this code, it simplifies the > > populate function. > > > > Signed-off-by: Olivier Matz > > One comment below, other than that > Reviewed-by: Andrew Rybchenko > > > --- > > lib/librte_mempool/rte_mempool.c | 47 ++++++-------------------------- > > 1 file changed, 8 insertions(+), 39 deletions(-) > > > > diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c > > index 3275e48c9..5e1f202dc 100644 > > --- a/lib/librte_mempool/rte_mempool.c > > +++ b/lib/librte_mempool/rte_mempool.c > > [snip] > > > @@ -531,36 +521,15 @@ rte_mempool_populate_default(struct rte_mempool *mp) > > goto fail; > > } > > - flags = mz_flags; > > - > > /* if we're trying to reserve contiguous memory, add appropriate > > * memzone flag. > > */ > > - if (try_iova_contig_mempool) > > - flags |= RTE_MEMZONE_IOVA_CONTIG; > > + if (min_chunk_size == (size_t)mem_size) > > + mz_flags |= RTE_MEMZONE_IOVA_CONTIG; > > mz = rte_memzone_reserve_aligned(mz_name, mem_size, > > - mp->socket_id, flags, align); > > - > > - /* if we were trying to allocate contiguous memory, failed and > > - * minimum required contiguous chunk fits minimum page, adjust > > - * memzone size to the page size, and try again. > > - */ > > - if (mz == NULL && try_iova_contig_mempool && > > - min_chunk_size <= pg_sz) { > > - try_iova_contig_mempool = false; > > - flags &= ~RTE_MEMZONE_IOVA_CONTIG; > > - > > - mem_size = rte_mempool_ops_calc_mem_size(mp, n, > > - pg_shift, &min_chunk_size, &align); > > - if (mem_size < 0) { > > - ret = mem_size; > > - goto fail; > > - } > > + mp->socket_id, mz_flags, align); > > - mz = rte_memzone_reserve_aligned(mz_name, mem_size, > > - mp->socket_id, flags, align); > > - } > > /* don't try reserving with 0 size if we were asked to reserve > > * IOVA-contiguous memory. > > */ > > [snip] > > > @@ -587,7 +556,7 @@ rte_mempool_populate_default(struct rte_mempool *mp) > > else > > iova = RTE_BAD_IOVA; > > - if (try_iova_contig_mempool || pg_sz == 0) > > + if (pg_sz == 0) > > I think (mz_flags & RTE_MEMZONE_IOVA_CONTIG) is lost here. Do you mean we should do instead if (pg_sz == 0 || (mz_flags & RTE_MEMZONE_IOVA_CONTIG)) populate_iova() else populate_virt() ? I would say yes, but it should be removed in patch 5/5. At the end, we don't want objects to be across pages, even with RTE_MEMZONE_IOVA_CONTIG. > > > ret = rte_mempool_populate_iova(mp, mz->addr, > > iova, mz->len, > > rte_mempool_memchunk_mz_free, >