> From: Thomas Monjalon <tho...@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. > > 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? This option will, into the foreseeable future, only impact the installation of those header files? 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? Thanks, Ben
