On Tue, Mar 31, 2020 at 02:29:08PM +0200, Thomas Monjalon wrote: > 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. I don't think its wise to assume that silence implies acceptance.
> 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. Why is that not possible by having napatech maintain an out-of-tree PMD? Theres no reason that can't be done. Neil > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
