From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 644EAA0C4D; Tue, 12 Oct 2021 23:50:13 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 43BDF410DF; Tue, 12 Oct 2021 23:50:13 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 04DE4410DC for ; Tue, 12 Oct 2021 23:50:12 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 97C225C00B1; Tue, 12 Oct 2021 17:50:11 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 12 Oct 2021 17:50:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= pcip8qtqBeVDkkQ2QU7AQVi+24Bu5jSoCv4A7sN0BGs=; b=FfnkEC1f51XQ05ro maxym3izDwTffqFN6vArHMtkqr131BzE3NcKrAJL0NebhtxXx40JwBWGrXvtpfJz pL9QEz4QUrarJAh/YbPbSE5lwOsLUcdjJVcvd7DWHVXXZ6a/4EFYcGEd0DrGlNEQ m2Sl9ky9AeK+FccNS6zpNCr7Ksdv2sMU3zJRbcyf3+w1m9jXmsdpoak7Ka2d4x37 2jyG750d2opjIeXqa+jxJoMj+4D6YOFNvpSc4IPTGy4HFivRhqSHc5rUoU5rD4iO tK1YL46HvOT/I20JBAFc89GRHIewEFXB1BAIiyTFCIAIotobxCYEo3y3emiFMIPg hIIxCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=pcip8qtqBeVDkkQ2QU7AQVi+24Bu5jSoCv4A7sN0B Gs=; b=avlglNca3CCZzcXgYv/to1FjMmKwESBbao0f6Ft8IorPY4Nk7ehdNrGDp cmmdcFC7B/RDWHDCMWMOK8wirUJ7p1/VvN9koA5ns7qF9U8opB4mJIFi/2FAmnCo t/CpFCV4EeUYkDymWuxWNLlehnddD6hdpHa+O8I9nEkXqzc29Nq45Uw/1VbP9SPF s5Pg9qiOrbsLDv/M+0PkIMK9JDt+tBBJ0ruJP8AUFW58luaz40j3SXCMgWa0RCpM S04UFUwhXaBraMzE0crYCQ7bWKrPlWRBx/RWZb1uuShERMbrL8ke0a11B6bXcoPG 9ELvBoxq6rRmLI4XUYyhWTwBDck1w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtlecutefuodetggdotefrodftvfcurf hrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghsucfo ohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtffrrg htthgvrhhnpeffvdffjeeuteelfeeileduudeugfetjeelveefkeejfeeigeehteffvdek feegudenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgv th X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Oct 2021 17:50:08 -0400 (EDT) From: Thomas Monjalon To: "Harris, James R" , "Walker, Benjamin" Cc: "Liu, Changpeng" , "Xia, Chenbo" , David Marchand , "dev@dpdk.org" , Aaron Conole , "Zawadzki, Tomasz" Date: Tue, 12 Oct 2021 23:50:04 +0200 Message-ID: <2268633.u4cMhumtpX@thomas> In-Reply-To: References: <20210910022402.26620-1-chenbo.xia@intel.com> <5522719.EOI0ZVpCj1@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" 12/10/2021 21:26, Walker, Benjamin: > > From: Thomas Monjalon > > 12/10/2021 18:59, Walker, Benjamin: > > > For networking drivers, maybe. But certainly years and years ago when SPDK > > was started no one recommended putting an nvme driver into DPDK. > > > > No one from SPDK project proposed such thing. > > I asked several times in person why that, and even the DPDK techboard asked for > > such a merge: > > https://mails.dpdk.org/archives/dev/2018-December/120706.html > > The reply: > > http://inbox.dpdk.org/dev/20181217141030.bhe5pwlqnzb3w3i7@platinum/ > > Even older question in 2015: > > http://inbox.dpdk.org/dev/6421280.5XkMhqyP4M@xps13/ > > > > For my part in these discussions, it was always about merging the governance of the projects rather than the code. I don't think a merger even occurred to anyone I spoke with during that - certainly it didn't to me. SPDK is huge and beyond its use of EAL/PCI doesn't share much in common with the rest of DPDK (SPDK uses lightweight green threading, all virtual addresses, etc.). Anyway, as I pointed out one of our key use cases for several users is the ability to replace DPDK entirely, so merging isn't an option. OK I understand, that's clear. I would be interesting to know if the NVMe drivers could be split in two parts: one part in DPDK, and the other part in SPDK for the non-DPDK case. I ask because it may ease things for DPDK integration in SPDK. There is probably a cost for the SPDK project, so it could be interesting to compare pros and cons, if possible at all. > > > This means that a distro-packaged SPDK cannot exist, because it cannot use a > > distro-packaged DPDK as a dependency. > > > > I don't think so. > > Once SPDK is packaged, what do you need from DPDK? > > I think you need only .so files for some libs like EAL and PCI, so that's available in > > the DPDK package, right? > > > > So is DPDK committed to maintaining the existing ABI, > such that the necessary symbols are still exported > even when enable_driver_sdk is off? Symbols required by drivers are necessarily exported. Do you think I am missing something? Do you need EAL internal functions? We should check which functions are called by SPDK, because there is a trend to export less functions if not needed. > This option will, into the foreseeable future, > only impact the installation of those header files? I don't see what else it could impact. > If that's the case, we can just copy the header file into SPDK, > as could anyone else that wants to continue using DPDK > to implement out of tree drivers. > Can you clarify if something like this scheme would be considered a supported use of DPDK? DPDK can be used by anybody as far as the (permissive) license is respected. I consider copying files as a source of sync issues, but you are free. In order to be perfectly clear, all the changes done around this option enable_driver_sdk share the goal of tidying stuff in DPDK so that ABI becomes better manageable. I think that nobody want to annoy the SPDK project. I understand that the changes effectively add troubles, and I am sorry about that. If SPDK and other projects can manage with this change, good. If there is a real blocker, we should discuss what are the options. Thanks for your understanding