> 23/10/2024 21:14, Akhil Goyal:
> > > 22/10/2024 14:06, Akhil Goyal:
> > > > > On Tue, Oct 22, 2024 at 8:06 AM Akhil Goyal
> wrote:
> > > > > > > The rational to NOT pull "Hardware abstraction library using the
> > > > > > > BAR
> > > > > > > address" to DPDK are
> > > > > > > -Yet another 200K
23/10/2024 21:14, Akhil Goyal:
> > 22/10/2024 14:06, Akhil Goyal:
> > > > On Tue, Oct 22, 2024 at 8:06 AM Akhil Goyal 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
> 22/10/2024 14:06, Akhil Goyal:
> > > On Tue, Oct 22, 2024 at 8:06 AM Akhil Goyal 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
22/10/2024 14:06, Akhil Goyal:
> > On Tue, Oct 22, 2024 at 8:06 AM Akhil Goyal 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
> > > >
On Tue, Oct 22, 2024 at 9:00 PM Stephen Hemminger
wrote:
>
> On Tue, 22 Oct 2024 12:08:22 +0200
> David Marchand wrote:
>
> > On Tue, Oct 22, 2024 at 8:06 AM Akhil Goyal wrote:
> > > > The rational to NOT pull "Hardware abstraction library using the BAR
> > > > address" to DPDK are
> > > > -Yet
On Tue, 22 Oct 2024 12:08:22 +0200
David Marchand wrote:
> On Tue, Oct 22, 2024 at 8:06 AM Akhil Goyal 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
> > > i
> On Tue, Oct 22, 2024 at 8:06 AM Akhil Goyal 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
On Tue, Oct 22, 2024 at 8:06 AM Akhil Goyal 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
22/10/2024 08:05, Akhil Goyal:
> > On Tue, Oct 22, 2024 at 3:00 AM Thomas Monjalon
> > 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
> On Tue, Oct 22, 2024 at 3:00 AM Thomas Monjalon
> 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
On Tue, Oct 22, 2024 at 3:00 AM Thomas Monjalon 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
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 a
Added rte_pmd_rvu_lf_bar_get() API to get BAR address
for application to configure hardware.
Signed-off-by: Akhil Goyal
---
doc/guides/rawdevs/cnxk_rvu_lf.rst| 7 ++
drivers/raw/cnxk_rvu_lf/cnxk_rvu_lf.c | 23 +++
drivers/raw/cnxk_rvu_lf/rte_pmd_cnxk_rvu_
13 matches
Mail list logo
