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 27EA4A00BE; Tue, 29 Oct 2019 12:03:44 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3FE881BEC1; Tue, 29 Oct 2019 12:03:43 +0100 (CET) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id C60D11BEC0 for ; Tue, 29 Oct 2019 12:03:41 +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-us3.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 880336C0065; Tue, 29 Oct 2019 11:03:39 +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; Tue, 29 Oct 2019 11:03:33 +0000 To: Olivier Matz CC: Vamsi Krishna Attunuru , , "Thomas Monjalon" , Anatoly Burakov , Jerin Jacob Kollanukkaran , Kokkilagadda , Ferruh Yigit References: <20190719133845.32432-1-olivier.matz@6wind.com> <20190719133845.32432-5-olivier.matz@6wind.com> <002c206e-b963-a932-1f57-6e7edb17c74b@solarflare.com> <20191028140705.d7t6b7s4k5av5lpr@platinum> From: Andrew Rybchenko Message-ID: <22a1cf58-4802-8594-5893-fddf3642df31@solarflare.com> Date: Tue, 29 Oct 2019 14:03:28 +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: <20191028140705.d7t6b7s4k5av5lpr@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-25008.003 X-TM-AS-Result: No-10.855600-8.000000-10 X-TMASE-MatchedRID: hls5oAVArl/mLzc6AOD8DfHkpkyUphL9BnIRIVcCWN9HZg0gWH5yUQWW 5akXXx2kSLX/wjk94KZJX9JkDz0D/kHGTQqAQaePKrDHzH6zmUUA+JHhu0IR5rjOUXWmQ3OW5aN AqIKMBMRPUFHAlz4GBBE0W5I8HGkWOWt3LpTk/GW/XwwG60j9NleOOwzb8N/GCDaSBZ23eppHIZ OimSs2+gvpvdjkPx/GYcXt25Cric5BWhPw1Oq2O+IfK/Jd5eHmJPe9IGDi6B1sMPuLZB/IR75X5 aZXuRYzUAJfPn7m1eWgVbxI8zQaQk1+zyfzlN7ygxsfzkNRlfKx5amWK2anSPoLR4+zsDTtX28x NpU0U3PfoGKYQqP6NEQlKLPmoQXrbOaIMYWBibQeOsaiVEvdWg== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--10.855600-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-25008.003 X-MDID: 1572347021-5e7jFQecelE3 Subject: Re: [dpdk-dev] [RFC 4/4] 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/28/19 5:07 PM, Olivier Matz wrote: > On Wed, Aug 07, 2019 at 06:21:58PM +0300, Andrew Rybchenko wrote: >> On 7/19/19 4:38 PM, Olivier Matz wrote: >>> When using iova contiguous memory and objets smaller than page size, >>> ensure that objects are not located across several pages. >> It looks like as an attempt to make exception a generic rule and >> I think it is not a good idea. >> >> mempool has a notion of IOVA contiguous/non-contiguous objects >> depending if PA or VA. rte_mempool_op_populate_default() gets >> a memory chunk which is contiguous in VA and, if iova is not bad, >> IOVA-contiguous. The patch always enforces page boundaries even >> if it is not required. For example, if memory chunk is IOVA_PA >> contiguous, the patch could result in holes and extra memory usage > Yes, it may increase memory usage, but the amount should be limited. > On the other hand, the new patchset provides enhancements that will > reduce the memory consumption. > > More importantly, it will fix the KNI + IOVA=VA issue. I also wonder if > this problem couldn't happen in case IOVA=PA. Are there any guarantees > that on all architectures a PA-contiguous in always VA-contiguous in the > kernel? I have no idea. The question is really interesting. I hope it is true, otherwise we're in trouble since it is assumed in the code as far as know.