[EXTERNAL] Re: [PATCH v3 3/9] raw/cnxk_rvu_lf: add PMD API to get BAR addresses

[Thomas Monjalon]

22/10/2024 08:05, Akhil Goyal:
> > On Tue, Oct 22, 2024 at 3:00 AM Thomas Monjalon <thomas at 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.