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?
