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 BA6B4A04FA; Mon, 3 Feb 2020 11:26:01 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A5C8E1BFE2; Mon, 3 Feb 2020 11:26:01 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 67F521BFE1 for ; Mon, 3 Feb 2020 11:25:59 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Feb 2020 02:25:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,397,1574150400"; d="scan'208";a="263366342" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.237.220.124]) ([10.237.220.124]) by fmsmga002.fm.intel.com with ESMTP; 03 Feb 2020 02:25:56 -0800 To: Dmitry Kozliuk , dev@dpdk.org Cc: Thomas Monjalon , Pallavi Kadam , Ranjit Menon , Harini.Ramakrishnan@microsoft.com, Stephen Hemminger References: <20200202233736.74bdf47f@Sovereign> From: "Burakov, Anatoly" Message-ID: <183db34b-0700-1b3a-a2ba-4d8ff6f8d65f@intel.com> Date: Mon, 3 Feb 2020 10:25:55 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <20200202233736.74bdf47f@Sovereign> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] Windows Support Plan 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 02-Feb-20 8:37 PM, Dmitry Kozliuk wrote: > Hi everyone! > Hi, > Primary topics to discuss: > > 1. Memory management (@Anatoly) > > 1.1. MM changed radically since v18.08 and dpdk-next-windows does not > implement it properly anyway, it allocates segment lists in a PCI bus > driver. My implementation closely follows the Linux one using > VirtualAlloc2() with XXX_PLACEHOLDER flags to reserve and commit > memory, but does not map hugepages to files. Is there > a consensus on MM approach in Windows? > > Anyway, I think EAL private MM API would have to be changed, > because memory reservation, allocation, and mapping are > completely different operations. Hiding this with an mmap() shim > doesn't look right, because mmap()'s behavior differs even among > Unix platforms. > > 1.2. In Windows, there is no /dev/mem to implement rte_virt2iova(), > so a simple kernel driver is required for mapping. Moreover, > Windows kernel abstracts IOMMU, so those physical addresses may > be unsuitable for DMA at all (see below). > I haven't really been following the Windows port much so i have no idea of how it works for now. The main reason DPDK memory management works the way it does is because of need to support multiprocess. In order to map memory in all processes, we need that space reserved (otherwise there's no guarantee that the newly mapped memory segment will be mapped in all processes, and it'll cause runtime failure). If it wasn't for that, we could allocate memory arbitrarily and as needed. Windows should either follow this model, or drop secondary support and go its own way - the internals are OS-specific anyway. If there are changes needed to private memalloc API to support the above, that's completely fine - that's why all of this stuff is internal-only :) As long as public API stays roughly the same, we should be good. Bear in mind that DPDK also supports external memory, you might need to make some allowances for that too. As for IOMMU - we don't support IOVA as VA addressing on FreeBSD, so if Windows port can only work with IOVA as PA, that's fine too. The question of IOVA mode really boils down to, do we control the DMA addresses (IOVA as VA mode), or does the system (IOVA as PA). I'm not familiar with how IOMMU works on Windows, but as long as it fits into that model and we keep the API, it should also be OK :) -- Thanks, Anatoly