On Tue, Mar 31, 2020 at 09:59:27PM +0200, Thomas Monjalon wrote: > 31/03/2020 21:51, Neil Horman: > > On Tue, Mar 31, 2020 at 07:58:45AM -0700, Stephen Hemminger wrote: > > > On Tue, 31 Mar 2020 12:39:17 +0000 > > > Michael Lilja <m...@napatech.com> wrote: > > > > > > > Hi, > > > > > > > > I appreciate the discussion. It would of course be nice if vendors > > > > could be allowed to use external libraries/drivers and have a DPDK shim > > > > but I also understand the concern. > > > > > > > > We have started the movement towards an open source variant of our NICs > > > > driver so that upstreaming to DPDK (and kernel) will be possible. The > > > > downside is that not all NICs will be supported, it is simply not worth > > > > the effort rewriting a legacy codebase. > > > > > > > > Thanks, > > > > Michael > > > > > > The downside is that any proprietary requirement means code is untestable > > > by > > > any CI or infrastructure. Therefore it is likely to be broken. > > > > > > > This. This is exactly my concern. Because the Napatech PMD is really just > > an > > interface to some proprietary code, no one outside of Napatech will have any > > insight or ability to test (or use) it. > > Michael just said above they are writing an open source driver. > Please encourage this great move. > Its a great move, sure, but it was a great move back in september of 2016 too: https://mails.dpdk.org/archives/dev/2016-September/046522.html
I don't see any progress in that direction, and I don't see how allowing a driver that needs closed source underpinnings encourages progress on that front. Is there a git tree of the open source driver somewhere that we can review? I'd be happy to look at integrating that driver, even if its in an incomplete state, as an encouraging step to complete that work. Neil
