On Thu, Sep 22, 2022 at 12:29 AM Harris, James R <james.r.har...@intel.com> wrote: > > 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?
In theory, yes they can change. But this is a price to pay, as no one seems willing to invest and maintain a stable API for PCI drivers. I just noticed that some parts of the cleanups I had proposed have been merged in SPDK. Next time, I prefer getting some feedback from SPDK community before my SoB is applied (or stripped) on modified patches. Thanks. -- David Marchand
