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? -- David Marchand
