From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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: <xms:EgNmYd5mFyrPjNwb-SNC1U_3ytcOAkNkTcpgrV_frmXxfz_TvuoxWw>
 <xme:EgNmYa5cAJMbMHzBawTL1qgrt5xc3O4_d-1B9B7EisStaibNK7Ddb_eeykchHBr7c
 WoI3a1zVB-RRHlAVA>
X-ME-Received: <xmr:EgNmYUciNDZKO2pTgrtYNqSJGJBLIkWASNPaax9qNnA6SgqPReB1J4YKjaT0KZ_ma5aZ9ZGPfhn_t4RjtrGaGfQBowmlrkCBvSILcOlJ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtlecutefuodetggdotefrodftvfcurf
 hrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecuuegr
 ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
 hrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghsucfo
 ohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtffrrg
 htthgvrhhnpeffvdffjeeuteelfeeileduudeugfetjeelveefkeejfeeigeehteffvdek
 feegudenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd
 enucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgv
 th
X-ME-Proxy: <xmx:EgNmYWLOVVvyvYLCbBx3tckUxpQvXX2eNJvb-7bk_onwgWrcWipAdQ>
 <xmx:EgNmYRKwkHUvV6aSW5eMmOQomCIkL0L2lKGlOmuWYlxAIG0HA4hjEg>
 <xmx:EgNmYfy_SXo6a8rI7_Dl-kSxQCfXA68ZVQkOfn2dJQvAtAMKOfQg_w>
 <xmx:EwNmYZ8_xGZ2eNzen8pKTe3u9F-bdD-FBXpSYU5xC6jHY_NIAQA0MQ>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 12 Oct 2021 17:50:08 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: "Harris, James R" <james.r.harris@intel.com>, "Walker,
 Benjamin" <benjamin.walker@intel.com>
Cc: "Liu, Changpeng" <changpeng.liu@intel.com>, "Xia,
 Chenbo" <chenbo.xia@intel.com>, David Marchand <david.marchand@redhat.com>,
 "dev@dpdk.org" <dev@dpdk.org>, Aaron Conole <aconole@redhat.com>, "Zawadzki,
 Tomasz" <tomasz.zawadzki@intel.com>
Date: Tue, 12 Oct 2021 23:50:04 +0200
Message-ID: <2268633.u4cMhumtpX@thomas>
In-Reply-To: <BYAPR11MB28244B99A5A21FC15FEA83EEEFB69@BYAPR11MB2824.namprd11.prod.outlook.com>
References: <20210910022402.26620-1-chenbo.xia@intel.com>
 <5522719.EOI0ZVpCj1@thomas>
 <BYAPR11MB28244B99A5A21FC15FEA83EEEFB69@BYAPR11MB2824.namprd11.prod.outlook.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

12/10/2021 21:26, Walker, Benjamin:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > 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