On Mon, 08 Jan 2018 16:15:47 +0100 Thomas Monjalon <tho...@monjalon.net> wrote:
> Hi, > > 08/01/2018 14:08, Finn Christensen: > > Hi Thomas, > > > > Thanks for bringing this discussion up again. > > > > The Napatech PMD is build on top of our proprietary driver. The reason is > > basically that we utilize many years of driver development and thus reuses > > the FPGA controlling code in the DPDK PMD. The Napatech driver suite is > > still closed source. > > The current NTNIC PMD dynamically links a Napatech proprietary NTAPI > > library to control the FPGA on our NICs. > > > > We did think of the PMD as being our responsibility to keep updated towards > > the Napatech NIC communication, and that we would be engaged and asked to > > modify accordingly if changes in DPDK required that (maintainer). > > Furthermore, the PMD compiles with no issues, when NTNIC is enabled. > > We have plans to write a stand-alone PMD, but this is not a small task to > > do, therefore we haven't got to that yet. > > This standalone PMD would be open and BSD licensed? > > > If the DPDK community would accept the dynamic linking to a proprietary > > library, from inside our PMD, then it would be great. > > Dynamic linking is OK. > I think we can accept such PMD at the condition that we can build it, > meaning we can easily download the build dependencies for free. > > > Let me know what you think. Or maybe you have ideas to what else we could > > do to make it upstream. > > My thinking is to allow every hardware to have a good DPDK support. > Every step in this direction is a progress. Also the API to the proprietary code must be separate from DPDK headers. Ideally the ABI for DPDK could evolve and the vendor code would not need to be updated.
