Hi, Raising this topic again.
As said in the past, it is better to have this PMD inside DPDK. We discussed some concerns, but I think the consensus was to integrate Napatech PMD anyway. I am sad that you did not feel welcome enough to follow up with patches during all these years. Please would you like to restart the upstreaming process? 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. > > If the DPDK community would accept the dynamic linking to a proprietary > library, from inside our PMD, then it would be great. > > Let me know what you think. Or maybe you have ideas to what else we could do > to make it upstream. > > Thanks, > Finn > > > >-----Original Message----- > >From: Thomas Monjalon [mailto:tho...@monjalon.net] > >Sent: 5. januar 2018 16:34 > >To: Finn Christensen <f...@napatech.com> > >Subject: Re: [dpdk-dev] standardize device identification > > > >It leads to a totally different question: > >Can we discuss again how to integrate your driver in DPDK upstream? > >Please explain again your situation in a new thread. >
