> 23/10/2024 21:14, Akhil Goyal:
> > > 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?
> > >
> > Ok, if we are having a separate file as driver_sdk_header,
> > We can also keep the BAR address API in that. Right?
>
> I think yes but it is redundant with the path
> rte_rawdev_info_get() -> get rte_device -> RTE_DEV_TO_PCI -> get bar addr
> Is it performance sensitive? In this case you could save/cache it.
It is about the ease of getting the BAR address.
rte_rawdev_info_get() -> get rte_device -> RTE_DEV_TO_PCI -> get bar addr
need 4 indirections/API to be used.
With this API, it is a single call.
Hence kept this API in v4.
If you have strong objection, I can remove it.
