> 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.
It seems the only contentious API is to get the BAR addresses.
All other APIs seems to be fine. Right?
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
If it is ok, I can send the next version with this change and documentation
update.
But we need to merge the library patch to get the device from dev_id.
https://patches.dpdk.org/project/dpdk/patch/20241008074000.3745855-1-gak...@marvell.com/
> >
> > Just to add one more point.
> > Even if we don’t use this API, we can still get the BAR addresses as David
> mentioned in another mail chain
> > rte_rawdev_info_get() -> get rte_device -> RTE_DEV_TO_PCI -> get bar addr
> >
> > This we can get for each raw PCI device, not just cnxk_rvu_lf. Right?
>
> Any PCI driver can do this (via bus_pci_driver.h header, exported with
> the enable_driver_sdk meson option).
> That's not exposed to application.
>
> Your abstraction library may cache this info if you think it will have
> an impact on fast path.
Yes, that can be done if we are not allowing the PMD API.
