On 9/12/2016 8:34 AM, fc at napatech.com (Finn Christensen) wrote: >> -----Original Message----- >> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] >> Sent: 10. september 2016 10:20 >> To: Finn Christensen <fc at napatech.com> >> Cc: Neil Horman <nhorman at tuxdriver.com>; dev at dpdk.org; >> stephen at networkplumber.org >> Subject: Re: [PATCH v3] ntnic: add PMD driver >> >> 2016-09-10 07:58, Finn Christensen: >>> From: Neil Horman [mailto:nhorman at 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 at 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! >
The patch is still waiting in the patchwork. This requires a high level discussion. Any suggestion on how to proceed?
