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 BD105A055A; Tue, 25 Feb 2020 15:21:13 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 860DB1BF8D; Tue, 25 Feb 2020 15:21:12 +0100 (CET) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 83870B62 for ; Tue, 25 Feb 2020 15:21:11 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Feb 2020 06:21:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,484,1574150400"; d="scan'208";a="384482040" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.237.220.130]) ([10.237.220.130]) by orsmga004.jf.intel.com with ESMTP; 25 Feb 2020 06:21:09 -0800 To: Ray Kinsella , dev@dpdk.org References: <276c85ed-ac2f-52c9-dffc-18ce41ab0f35@ashroe.eu> From: "Burakov, Anatoly" Message-ID: Date: Tue, 25 Feb 2020 14:21:08 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <276c85ed-ac2f-52c9-dffc-18ce41ab0f35@ashroe.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] vfio: map contiguous areas in one go 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 25-Feb-20 1:49 PM, Ray Kinsella wrote: > Hi Anatoly, > > On 25/02/2020 13:24, Anatoly Burakov wrote: >> Currently, when we are creating DMA mappings for memory that's >> either external or is backed by hugepages in IOVA as PA mode, we >> assume that each page is necessarily discontiguous. This may not >> actually be the case, especially for external memory, where the >> user is able to create their own IOVA table and make it >> contiguous. This is a problem because VFIO has a limited number >> of DMA mappings, and it does not appear to concatenate them and >> treats each mapping as separate, even when they cover adjacent >> areas. >>> Fix this so that we always map contiguous memory in a single >> chunk, as opposed to mapping each segment separately. > > Can I confirm my understanding. > > We are essentially correcting user errant behavior, > trading off startup/mapping time to save IOMMU resources? > That's not quite what we're doing. First of all, in terms of "trading startup/mapping time", i think this will actually be faster because the DMA map is the more resource-intensive part of this loop by far, and we're doing _less_ of those (because we're concatenating). We're also doing the same number of loop iterations as before. To be perfectly clear: we're not reordering segments here - segments have to be VA- and IOVA-contiguous in the first place, otherwise we're breaking them up. It's just that previously, we were also breaking up contiguous segments into separate, per-page mappings, but now we concatenate them. -- Thanks, Anatoly