Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs

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>
Subject: Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
Date: Tue, 12 Oct 2021 23:50:04 +0200	[thread overview]
Message-ID: <2268633.u4cMhumtpX@thomas> (raw)
In-Reply-To: <BYAPR11MB28244B99A5A21FC15FEA83EEEFB69@BYAPR11MB2824.namprd11.prod.outlook.com>

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