22/10/2024 14:06, Akhil Goyal: > > On Tue, Oct 22, 2024 at 8:06 AM Akhil Goyal <gak...@marvell.com> wrote: > > > > The rational to NOT pull "Hardware abstraction library using the BAR > > > > address" to DPDK are > > > > -Yet another 200K of driver C++ code which does not make sense to keep > > > > in dpdk.org > > > > -It can not implemenent any of the current subsystems > > > > > > > > In this context, let me know what you think? > > > > This hardware abstraction library will have to call some driver > > specific API (like the added raw/cnxk_rvu API). > > Can this library directly use the PCI driver API, and call the cnxk > > common driver? > > If so, there is no need to add another driver API (that breaks > > layers), and the rawdev driver is only about adding the mailbox > > features. > > cnxk common has a lot of internal APIs which > we do not want to expose directly to application.
Actually the target is an out-of-tree driver, not an application. > It seems the only contentious API is to get the BAR addresses. > All other APIs seems to be fine. Right? Interrupt management is also something we would like to see reserved to drivers. > If so, we can remove that API and get the bar addresses as you suggested > below. > rte_rawdev_info_get() -> get rte_device -> RTE_DEV_TO_PCI -> get bar addr > via bus_pci_driver.h header, exported via enable_driver_sdk option Yes please, it is better to avoid confusion between driver and application. Any driver type layer should be exposed only when the Meson option enable_driver_sdk is enabled. You probably should export the interrupt functions in a separate file through driver_sdk_headers, so it is clear it is not an application level. Does it apply to the mailbox functions as well? > If it is ok, I can send the next version with this change and documentation > update. Yes, thanks.
