On Tue, Oct 22, 2024 at 9:00 PM Stephen Hemminger <step...@networkplumber.org> wrote: > > On Tue, 22 Oct 2024 12:08:22 +0200 > David Marchand <david.march...@redhat.com> wrote: > > > On Tue, Oct 22, 2024 at 8:06 AM Akhil Goyal <gak...@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.
