From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id E07F42BB0 for ; Mon, 21 Nov 2016 14:47:46 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga105.fm.intel.com with ESMTP; 21 Nov 2016 05:47:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,675,1473145200"; d="scan'208";a="1062342718" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.57]) ([10.237.220.57]) by orsmga001.jf.intel.com with ESMTP; 21 Nov 2016 05:47:43 -0800 To: Finn Christensen , Thomas Monjalon References: <20160908111424.14127-1-fc@napatech.com> <20160909135108.GA15908@hmsreliant.think-freely.org> <1913786.NX7M2nQ5WY@xps13> <9b58ce3a52404addaa2f1d972f345097@napatech.com> From: Ferruh Yigit Cc: Neil Horman , dev@dpdk.org, stephen@networkplumber.org Message-ID: Date: Mon, 21 Nov 2016 13:47:43 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9b58ce3a52404addaa2f1d972f345097@napatech.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v3] ntnic: add PMD driver X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 13:47:47 -0000 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 >> Cc: Neil Horman ; 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 >>>>> --- >>>>> 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?