> On Jul 28, 2022, at 8:26 AM, David Marchand <david.march...@redhat.com> wrote: > > This is a PoC for hiding the rte_bus, rte_driver and rte_device objects. > And mark associated driver only API as internal. > > A good amount of the patches are preparation work on rte_bus.h, > rte_dev.h, rte_devargs.h and rte_eal.h headers, removing dependencies > between them. > > PCI bus specific handling are removed from testpmd, unit tests and > examples. > > After this series, driver-only API headers for registering to buses are > not exported anymore, unless the enable_driver_sdk meson option is > selected. > > New accessors for rte_bus, rte_driver and rte_device have been added, > marked with an experimental tag first when introducing them, and later > in the series marked as stable since external users will want to use > those drop-in replacements right away. > > A check is added to ensure we won't pollute app/ and examples/ again, > though some unit tests are left intentionnally untouched as they test > some internals of DPDK. > > Comments welcome.
Hi David, I certainly understand wanting to hide those objects to avoid ABI maintenance. SPDK is using fields directly from some of those structures today, but I think all of them could be replaced with associated helper functions. This was discussed a bit late last year related to Chenbo’s earlier patch set: https://www.mail-archive.com/dev@dpdk.org/msg222560.html It looks like SPDK never got back to the DPDK project on exactly what APIs we would need, to see if DPDK could still support a minimal API without requiring the enable_driver_sdk flag. I’m generating an exact list, but it would be rendered moot depending on the next question... 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. If you’re open to this, we (SPDK) can make a proposal on exactly what we would need to keep SPDK working with a standard DPDK build. Thanks, Jim
