From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 826D5A00BE; Wed, 30 Oct 2019 08:56:52 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 285E91BEB5; Wed, 30 Oct 2019 08:56:52 +0100 (CET) Received: from dispatchb-us1.ppe-hosted.com (dispatchb-us1.ppe-hosted.com [148.163.129.53]) by dpdk.org (Postfix) with ESMTP id 9382E1BDAC for ; Wed, 30 Oct 2019 08:56:50 +0100 (CET) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us2.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id A3E5E68005A; Wed, 30 Oct 2019 07:56:48 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 30 Oct 2019 07:56:40 +0000 To: Olivier Matz CC: , Anatoly Burakov , Ferruh Yigit , "Giridharan, Ganesan" , Jerin Jacob Kollanukkaran , Kiran Kumar Kokkilagadda , Stephen Hemminger , "Thomas Monjalon" , Vamsi Krishna Attunuru References: <20190719133845.32432-1-olivier.matz@6wind.com> <20191028140122.9592-1-olivier.matz@6wind.com> <20191028140122.9592-6-olivier.matz@6wind.com> <08a69641-9876-1f28-0f43-06f5d858d4c7@solarflare.com> <20191029173442.4bzpefjs2ivp5yk4@platinum> From: Andrew Rybchenko Message-ID: <67b17385-9fd8-7644-09c4-e408e1b2ce08@solarflare.com> Date: Wed, 30 Oct 2019 10:56:36 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191029173442.4bzpefjs2ivp5yk4@platinum> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-25010.003 X-TM-AS-Result: No-9.258600-8.000000-10 X-TMASE-MatchedRID: VfovoVrt/obmLzc6AOD8DfHkpkyUphL91mc05rOhnpJpsnGGIgWMmQWW 5akXXx2kSLX/wjk94KYtdNlwKbTDEj9ppLyGsH/YGUlF/M3Dxp9nLk6tQLcY6RMu6ersnFy9pL8 Qgaut+5JgoLabqpGHzRTGOSBWljRQI1KAjP3DpcDBFOikWBnGHQKflB9+9kWVf2dEskHXJhBGVK ommfqPJx0F+gtxjusKRQCr78CB4Oi/yjNcwjTwjOLbvXwDQz25rYIJqyGcXHVHZg0gWH5yUfvBI KrCyn42iZNHeXaejyaRk6XtYogiau9c69BWUTGwiYZyrULQL1bEQdG7H66TyMdRT5TQAJnAbe5U BddX3FEMCYiWl8nKGq9U2WsSxNs+qQij1hGTXqGeqD9WtJkSIw== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--9.258600-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-25010.003 X-MDID: 1572422210-MVP8fRqjQiRu Subject: Re: [dpdk-dev] [PATCH 5/5] mempool: prevent objects from being across pages 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 10/29/19 8:34 PM, Olivier Matz wrote: > On Tue, Oct 29, 2019 at 01:59:00PM +0300, Andrew Rybchenko wrote: >> On 10/28/19 5:01 PM, Olivier Matz wrote: >>> When populating a mempool, ensure that objects are not located across >>> several pages, except if user did not request iova contiguous objects. >> I think it breaks distribution across memory channels which could >> affect performance significantly. > With 2M hugepages, there are ~900 mbufs per page, and all of them will > be distributed across memory channels. For larger objects, I don't think > the distribution is that important. Yes, that's true. I was thinking about the case when page is smaller. > With small pages, that may be true. I think the problem was already > there except in IOVA=VA mode. I don't know any good real examples. In theory before even small pages could be merged together and populated as one big chunk. Right now merging does not make sense since page boundaries will be respected by default anyway. > This should be fixable, but I'm not sure a use-case where we can see a > regression really exists. Agreed. If total object size allows it, it is possible to spread offset from page boundary. I don't know either if it is critical or not.