From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) by dpdk.org (Postfix) with ESMTP id F3F19592F for ; Tue, 25 Oct 2016 16:38:02 +0200 (CEST) Received: by mail-lf0-f50.google.com with SMTP id d20so15817674lfj.5 for ; Tue, 25 Oct 2016 07:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=NfvYulHhWZoQKZt7l1HSnlEa/S2sVb7+DE6sE06GLFk=; b=MwjLn1DEg5oZt90GdQ68r45TUUlI/ZExAtwI7usxnlO3ntheG+ln3gsV2W2nI+l5x/ D6fyJzDrKuRcU+jxPb+aXzT5VimG3XupD6T5sdlFlR25a9oBFhnaYpNPcwN/MOXq6Mxt U/f4zf7qNxKFr4+U+YmYjWN6HagaMwE8PdBDPDueFOu34ugbPQdsF4MvUO3M7CR+DX8Z 3qgvuJRlXrTbLhkQeeoJiAfnssg5Npv87hXGu+IWKJJNkrJUzGfTaw6uIutBr2oTUQWD JA84WnvekjnOIg1eDrASDCpGZ0ymvGHwGz9BJI0J5uMhtZea+fJ/TiuVLn8xKuXkXC4O 19nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=NfvYulHhWZoQKZt7l1HSnlEa/S2sVb7+DE6sE06GLFk=; b=ZAU3m8QLWZeTVc+7U5K4NVSBCDpiGZZJd0rNA02Hhe0SwiAZ4citR+yZF2KcJCnvp9 9jSNquF9A3xBi/iwH7OzfCYy1Hb7JSErXfxSLahFKZfOLZY12TpoUVGMq7zG0jxhF4VO verMStNvLG1PAa7wbcXWuRgCQy9P9n7tWDQTkQDL+Chtoiv6w6ylQ1GLkGALhlOC7eZw uvAEPdeI4gnFPsYYGsjwjI5PDaDuImn53cpRzg3G9rqnVvkNkwleqnleWNdcDZmNuDF6 QZ6ZlbRj3hcndGFuK+PKBhqIj0CbrFxwE2lKfngmfOduzu+bhRKGnGX0i+kb73XG1G0w iCjA== X-Gm-Message-State: ABUngvd+2Z8n2EKbYlTrrp5AcztmuCT7WbMIyUxnEHvNL0dnAtIngWpKnLbG9HnSY8BT+XNQ X-Received: by 10.194.203.6 with SMTP id km6mr16507912wjc.226.1477406282395; Tue, 25 Oct 2016 07:38:02 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id f194sm4052661wmg.12.2016.10.25.07.37.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Oct 2016 07:37:31 -0700 (PDT) From: Thomas Monjalon To: Olivier MATZ Cc: dev@dpdk.org, "Ananyev, Konstantin" , "Dai, Wei" , "Gonzalez Monroy, Sergio" , "Tan, Jianfeng" Date: Tue, 25 Oct 2016 16:37:30 +0200 Message-ID: <2906356.2N5hSckZQm@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <57FFA2C9.9000603@6wind.com> References: <1476351445-18102-1-git-send-email-wei.dai@intel.com> <2601191342CEEE43887BDE71AB9772583F0C12EF@irsmsx105.ger.corp.intel.com> <57FFA2C9.9000603@6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] mempool: fix search of maximum contiguous pages X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 14:38:03 -0000 2016-10-13 17:05, Olivier MATZ: > Hi Wei, > > On 10/13/2016 02:31 PM, Ananyev, Konstantin wrote: > > > >> > >>>>> diff --git a/lib/librte_mempool/rte_mempool.c > >>>>> b/lib/librte_mempool/rte_mempool.c > >>>>> index 71017e1..e3e254a 100644 > >>>>> --- a/lib/librte_mempool/rte_mempool.c > >>>>> +++ b/lib/librte_mempool/rte_mempool.c > >>>>> @@ -426,9 +426,12 @@ rte_mempool_populate_phys_tab(struct > >>>>> rte_mempool *mp, char *vaddr, > >>>>> > >>>>> for (i = 0; i < pg_num && mp->populated_size < mp->size; i += n) { > >>>>> > >>>>> + phys_addr_t paddr_next; > >>>>> + paddr_next = paddr[i] + pg_sz; > >>>>> + > >>>>> /* populate with the largest group of contiguous pages */ > >>>>> for (n = 1; (i + n) < pg_num && > >>>>> - paddr[i] + pg_sz == paddr[i+n]; n++) > >>>>> + paddr_next == paddr[i+n]; n++, paddr_next += pg_sz) > >>>>> ; > >>>> > >>>> Good catch. > >>>> Why not just paddr[i + n - 1] != paddr[i + n]? > >>> > >>> Sorry, I meant 'paddr[i + n - 1] + pg_sz == paddr[i+n]' off course. > >>> > >>>> Then you don't need extra variable (paddr_next) here. > >>>> Konstantin > >> > >> Thank you, Konstantin > >> 'paddr[i + n - 1] + pg_sz = paddr[i + n]' also can fix it and have straight meaning. > >> But I assume that my revision with paddr_next += pg_sz may have a bit better performance. > > > > I don't think there would be any real difference, again it is not performance critical code-path. > > > >> By the way, paddr[i] + n * pg_sz = paddr[i + n] can also resolve it. > > > > Yes, that's one seems even better for me - make things more clear. > > Thank you for fixing this. > > My vote would go for "addr[i + n - 1] + pg_sz == paddr[i + n]" > > If you feel "paddr[i] + n * pg_sz = paddr[i + n]" is clearer, I have no > problem with it either. No answer from Wei Dai. Please Olivier advise what to do with this patch. Thanks