> On Aug 30, 2022, at 8:09 AM, David Marchand <david.march...@redhat.com> wrote: > > On Mon, Aug 29, 2022 at 7:12 PM Walker, Benjamin > <benjamin.wal...@intel.com> wrote: >>>> Can we keep rte_pci_register(), or a new variation of it that keeps >>>> the rte_pci_driver structure hidden? Hiding rte_pci_register() would >>>> mean SPDK can no longer work with a packaged DPDK. Or the DPDK >>>> packages would need to set enable_driver_sdk which I suspect is not the >>> intent. >>> >>> What do you think if SPDK maintains a copy of the internal headers? >>> >>> The internal API are not supposed to change that often, but we (DPDK) won't >>> guarantee it. >>> This would still put some maintenance burden on SPDK but I think it is a >>> good >>> compromise. >>> >> >> Would these internal symbols be considered part of the public/official ABI? >> When > > What do you mean by "public/official"? > If you mean the "stable" ABI (as described in the ABI policy document > and for which compatibility is preserved across minor versions of the > ABI), the answer is no: internal symbols are not part of it. > > >> SPDK goes to dynamically load a shared DPDK library, how can we detect >> whether it's a version that we support linking against? > > The runtime version of a DPDK library is available via rte_version(). > > > As for the PCI drivers that SPDK wants to register in DPDK, what do > you think if SPDK people added and maintained a "generic" PCI driver > in DPDK. > This driver would expose a new API (which can not re-expose internal > structures, like rte_pci_driver and consorts) and ensure its ABI is > maintained in the long term. > This makes me think of pci-stub, but in DPDK. > > I did not think too much about it and I don't understand what SPDK > requires, but is there something wrong with this approach?
The stub driver idea is interesting. In the past we’ve needed access to more than what a stub driver would provide - for example, to work around kernel vfio + pci bugs when we probe 24 NVMe SSDs behind a PCIe switch that is hot-inserted, or conversely handling hot removal of that same switch. So I’m worried that even if we do the stub driver, we end up running into a case where we need these header file copies anyways. Not ruling the stub driver out, but I think it's a longer-term goal, not something we would have ready for 22.11 obviously. So sticking with the internal header copies for now, this works fine for LTS and non-LTS releases. What about stable releases (i.e. 22.11.1)? IIUC, these header files could change in a stable release since they are no longer part of the ABI? -Jim
