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 04887A051C; Tue, 11 Feb 2020 11:05:10 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 625DB2B89; Tue, 11 Feb 2020 11:05:10 +0100 (CET) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 37D951DB9 for ; Tue, 11 Feb 2020 11:05:08 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Feb 2020 02:05:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,428,1574150400"; d="scan'208";a="233405868" Received: from unknown (HELO [10.237.220.105]) ([10.237.220.105]) by orsmga003.jf.intel.com with ESMTP; 11 Feb 2020 02:05:05 -0800 To: Dmitry Kozlyuk Cc: dev@dpdk.org, Thomas Monjalon , Pallavi Kadam , Ranjit Menon , Harini.Ramakrishnan@microsoft.com, Stephen Hemminger References: <20200202233736.74bdf47f@Sovereign> <183db34b-0700-1b3a-a2ba-4d8ff6f8d65f@intel.com> <20200208230904.35f615de@Sovereign> From: "Burakov, Anatoly" Message-ID: <2080bf2a-8062-fa15-61c0-9cce55cec999@intel.com> Date: Tue, 11 Feb 2020 10:05:04 +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: <20200208230904.35f615de@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 08-Feb-20 8:09 PM, Dmitry Kozlyuk wrote: >> 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. > > I think Windows should support multi-process, because there is a demand and > an ongoing design effort for multi-tenancy and resource arbitration [0]. > Until Windows kernel implements "secure API" for the architecture proposed by > [0] (if it does at all), DPDK multi-process model can to some point support > the features desired. For example, a primary process may be a service > performing resource arbitration for applications being secondary processes. > >> Bear in mind that DPDK also supports external memory, you might >> need to make some allowances for that too. > > I haven't considered external memory yet. Does it need anything beyond > mapping VA to IOVA? No, just a few checks here and there. The brunt of the mapping is on the shoulders of the user, and "external memory API" is really just registering this memory with DPDK so that calls like rte_virt2memseg() work correctly. > >> 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 :) > > AFAIK, Windows doesn't expose IOMMU either to applications or drivers. Do I > understand correctly that implies only IOVA as PA can be supported, because > mappings can't be set up? In general, yes. The name probably doesn't match very well, admittedly, but that's the equivalent as far as software is concerned. That's not a problem - FreeBSD doesn't support IOVA as VA either :) > > The trouble is, PA cannot generally be used if IOMMU is present, but there > is no way to tell if it is. Windows kernel offers API to allocate buffers for > DMA [1], but MM doesn't know if it allocates memory for DMA or not, even if > that kernel API would be exposed. If I got it right, DPDK just can't be used > on Windows with IOMMU enabled (can't tell for VMs that don't see IOMMU). > > [0]: > https://www.dpdk.org/wp-content/uploads/sites/35/2018/12/RMenonOCardona_Improving-Security-in-Windows-DPDK.pdf > [1]: > https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nc-wdm-pallocate_common_buffer_ex > -- Thanks, Anatoly