31/03/2020 14:17, Neil Horman: > On Tue, Mar 31, 2020 at 01:25:25PM +0200, Thomas Monjalon wrote: > > 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? > > > Whats changed here?
Nothing changed, except years. > I still don't see what the advantage is to accepting this code in the DPDK > tree. > No one will be able to use it without accepting Napatechs license for their > underlying library. As such, the code can't really be maintained at all by > anyone other than Napatech in the community, and so may as well just be > maintained as an out of tree driver. You are the only one having this concern. Nobody from the Technical Board looks to be against the acceptance. The advantage is simple: Napatech customers will be able to run any DPDK version. > > 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. > > > > > > > > > > > > > > > >
