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 E32E1A04B3; Sat, 8 Feb 2020 21:09:12 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1FC011BF81; Sat, 8 Feb 2020 21:09:12 +0100 (CET) Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) by dpdk.org (Postfix) with ESMTP id DDD291DB9 for ; Sat, 8 Feb 2020 21:09:10 +0100 (CET) Received: by mail-lf1-f50.google.com with SMTP id l18so1561714lfc.1 for ; Sat, 08 Feb 2020 12:09:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ums76S9VI3MkkJkaP05pGSE7JS8DWC8mPjw0uQHtpHk=; b=EUkg72YEggL+3Rs4J3hycyqa4v70Rjwhh7EdLq0pKES9c26PPCsBEH7IvsvDWPgGYT Lkrh6hb/FOP1SkPAAtwGdB91900TunEuXFt7dQ0GK522Q/jcIA4j9GUVV/SEC0oi8JOh B+wEmzabiktqAih/WnHW4GPia3YyFl/HQRLCHzJ2BO2Yz1xBCLLIy9o89bwbi4tgGGG7 11HoxcJLrpHIM3mgGfHudYswATmaOzmwzY0LoVmmpfot5jwWUo9WtV7yOwuTfs3x0M2H RFto80D/DAqYfg5Zux96R8sVHlXxNmKjWtPNi5116On6MWXJrGnN1RyB8HjcqPZbbOHB 6zKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ums76S9VI3MkkJkaP05pGSE7JS8DWC8mPjw0uQHtpHk=; b=Lycc9XOQOOJST/pJxHmT5FA/g3aXfqzw+cY0SZsSDM4ml6SRavHB3AZUeRdLezYeRT ppSheUHgipx16nRMD4O9fQ331x+IgeZxEa30UDjZLLGXR2eC62YDJKVKMISizQ/3M4P+ IukK69TrJ6cYGcbT9r3xxXKmhl7XNUMtDeWpGEB1CuMOvOT0FhX7uX9qAFBClptZX+Il YkQi9x5hgLV4bteqATHYWKTgn2P9qM5ja6ESFNJ8db8z8lebJ2Nr1Un/wURnTnVINuAi YD++QY4koQm/qc6pmpHVfHXPFMQ8uWsdW4Q14cn2GQArEfj5Uq6T8erQzRkkLg3K/au9 T4XQ== X-Gm-Message-State: APjAAAWQFdk3sFUBW15NhqwtmoWrdQ/4PgSNwingeMAgaC7p1ORiOsg0 rLMj+wov8dC1wzQM+4nzXRQ= X-Google-Smtp-Source: APXvYqzksW+TSvEPo1q6n4EBW4o+3VyNNYP1UrXrSJtABO/hKLZySFP8QnEtIYbvAboTPJMll7J/9w== X-Received: by 2002:a19:c3ce:: with SMTP id t197mr2553030lff.174.1581192550250; Sat, 08 Feb 2020 12:09:10 -0800 (PST) Received: from Sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id n11sm3610621ljg.15.2020.02.08.12.09.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Feb 2020 12:09:09 -0800 (PST) Date: Sat, 8 Feb 2020 23:09:04 +0300 From: Dmitry Kozlyuk To: "Burakov, Anatoly" Cc: dev@dpdk.org, Thomas Monjalon , Pallavi Kadam , Ranjit Menon , Harini.Ramakrishnan@microsoft.com, Stephen Hemminger Message-ID: <20200208230904.35f615de@Sovereign> In-Reply-To: <183db34b-0700-1b3a-a2ba-4d8ff6f8d65f@intel.com> References: <20200202233736.74bdf47f@Sovereign> <183db34b-0700-1b3a-a2ba-4d8ff6f8d65f@intel.com> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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" > 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? > 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? 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 -- Dmitry Kozlyuk