Re: [dpdk-dev] [PATCH v3] ntnic: add PMD driver

[Finn Christensen <fc@napatech.com>]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: 10. september 2016 10:20
> To: Finn Christensen <fc@napatech.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>; dev@dpdk.org;
> stephen@networkplumber.org
> Subject: Re: [PATCH v3] ntnic: add PMD driver
>
> 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.

The ntnic PMD is not enabled by default and I think it should not be either. To
enable it in a distribution for general purposes seems wrong. In that respect
we see no difference between the PCAP PMD and this ntnic PMD.

> > 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.

Thanks. I will be happy to discuss this further, so that we can get to a conclusion.
If the outcome is that the majority of the community does not like the idea that
upstream supported PMDs has external linking dependencies to closed source
libraries, then it is ok with us(a pity though). But then it might be a good idea to
make that decision clear to everybody else by putting in a clause into the
contribution section of the DPDK guide, or somewhere else in the guide.

In our opinion, the inclusion of the ntnic PMD into upstream DPDK, does not
seem to be any different than that of the PCAP PMD, since that is also
dependent on external header files and externally built libraries.
Of course we see the difference in open source vs close source library. But we
cannot see that is has any influence in the usage or functionality of the DPDK.

Thanks for this discussion!

Disclaimer: This email and any files transmitted with it may contain confidential information intended for the addressee(s) only. The information is not to be surrendered or copied to unauthorized persons. If you have received this communication in error, please notify the sender immediately and delete this e-mail from your system.