[RFC v3 00/26] Bus and device cleanup for 22.11

[Harris, James R]

> On Aug 30, 2022, at 8:09 AM, David Marchand <david.marchand at redhat.com> wrote:
> 
> On Mon, Aug 29, 2022 at 7:12 PM Walker, Benjamin
> <benjamin.walker at 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