12/10/2021 21:26, Walker, Benjamin: > > 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.
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
