Re: [PATCH v3] ntnic: add PMD driver

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2016-09-10 07:58, Finn Christensen:
> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > On Fri, Sep 09, 2016 at 12:48:38PM +0000, Finn Christensen wrote:
> > > This is the Napatech NTNIC Poll Mode Driver (PMD) for DPDK.
> > >
> > > This patch adds support for Napatech NICs to DPDK. This is the
> > > initial implementation.
> > >
> > > Signed-off-by: Finn Christensen <fc@napatech.com>
> > > ---
> > > v3:
> > >   * Removed the need for binary libraries on build
> > > v2:
> > >   * Added information how to build the PMD without NIC
> > >     Board Support Package
> > >   * Fixed some formatting issues
> > 
> > So, this is a step in the right direction, but I think its solving the wrong
> > problem.  If you have a dependency on an external library, thats ok, and
> > accessing it via dlopen makes it possible to build the library without having
> > that library present, but it not really in keeping with the spirit of what I
> > meant.  This driver is still effectively dependent on a binary blob that we
> > have
> > no visibility into.  The better solution is releasing the source for the ntnic
> > and ntos libraries.  The license file in the referenced git tree indicates its
> > BSD licensed, so I don't think there should be a problem in doing that.
> >
> > Neil
> >
> No, unfortunately the ntapi is not BSD licensed, only the header files that
> you can freely download are.
> We are building this NT NIC by using parts or our technology from our
> capture adapters and that is using closed source software.
> 
> We are new to opensource and we want to go that way, but we haven't
> yet a complete stand-alone driver ready that we can put into the DPDK
> PMD to have a complete self contained and open sourced DPDK PMD, that
> only needs the actual HW NIC plugged in to run.
> Therefore this version is implemented as a virtual device, exactly like the
> PCAP PMD driver is, and it runs on top of a driver that follows the NIC itself.
> 
> In regards to the DPDK functionality we do not see that anything is missing.
> I cannot either see where we should add source code, because it is not part
> of the DPDK package and it should not be either.
> 
> One of the things I really liked about the DPDK open source project is that it
> uses BSD licensing not GPL. Therefore, I must admit, we  completely failed
> to see that the "spirit" of the DPDK community is not really BSD. Our view
> of this community was that the main driving force of it was to be able to
> make DPDK run on everything anywhere effectively, in a global contributing
> community, without  any legally constrains prohibiting us to do so.

It is difficult to define what is the spirit of a community, especially only
after few mail exchanges.
I agree that running on everything anywhere is a nice goal.
Here Neil, as a RedHat developer, is probably concerned about enabling your
driver in a distribution. It seems your model is not compatible with the
"anywhere goal" and will be disabled in that case, until it is fully open.

> However, this is our standing, and I don't know what else to do.
> Please advise or NAK this PMD.

I do not remember having already seen such model in DPDK.
So we need to think about the implications a bit more.
(Comments/discussions are welcome)
Thanks for your patience.