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

[Jerin Jacob <jerinjacobk@gmail.com>]

On Tue, Oct 22, 2024 at 9:00 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Tue, 22 Oct 2024 12:08:22 +0200
> David Marchand <david.marchand@redhat.com> wrote:
>
> > On Tue, Oct 22, 2024 at 8:06 AM Akhil Goyal <gakhil@marvell.com> 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
> > > >
> > > > In this context, let me know what you think?
> >
> > This hardware abstraction library will have to call some driver
> > specific API (like the added raw/cnxk_rvu API).
> > Can this library directly use the PCI driver API, and call the cnxk
> > common driver?
> > If so, there is no need to add another driver API (that breaks
> > layers), and the rawdev driver is only about adding the mailbox
> > features.
> >
>
>
> This seems related to the discussion of binary drivers in the TB.
> There was discussion that any/all use of binary drivers means that the any
> crashes in DPDK could be cause by that binary. Like the Linux kernel,
> we need a "tainted" policy. Where any bug reports on tainted use of DPDK
> are just rejected and forwarded to the binary driver vendor.

It is not a binary driver situation, it is more out of tree driver
situation i.e DPDK does not depend on any binary drivers. It is the
same as exposing rte_pci_device via enable_driver_sdk meson option.