Re: [EXTERNAL] Re: [PATCH v3 3/9] raw/cnxk_rvu_lf: add PMD API to get BAR addresses

[Thomas Monjalon <thomas@monjalon.net>]

22/10/2024 14:06, Akhil Goyal:
> > On Tue, Oct 22, 2024 at 8:06 AM Akhil Goyal <gakhil@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.