22/10/2024 08:05, Akhil Goyal: > > 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.
I'm not confortable taking this decision alone. I wonder what others think? Adding the techboard as Cc.
