> On Tue, Oct 22, 2024 at 3:00 AM Thomas Monjalon <tho...@monjalon.net> > wrote: > > > > 08/10/2024 20:49, Akhil Goyal: > > > Added rte_pmd_rvu_lf_bar_get() API to get BAR address > > > for application to configure hardware. > > > > In my opinion, we should not return PCI BAR addresses to an application. > > We should make an effort to have all theses details managed in the driver. > > Giving this level of access to an app is a door we should probably not open. > > I agree with this in the traditional application laying context. > Typical layering is "driver" -> "device class like ethdev" ->application. > > In this case, This raw driver is a proprietary 5G PCIe device where > the DPDK does not have a subsystem for that. So application is layered > to have "Hardware abstraction library" and "Application" > i.e "cnxk lf raw driver" -> "Hardware abstraction library using the > BAR address" -> "Real Application". The real application is taking > only to the Hardware abstraction library. > > 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?
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? This API is just avoiding the hassle of application to use 4 calls/indirections to get the BAR address. So having an API to improve usability should not be an issue.
