From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail01.napatech.com (mail01.napatech.com [188.120.77.121]) by dpdk.org (Postfix) with ESMTP id 07B4F2904 for ; Mon, 12 Sep 2016 09:34:23 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2FPAQCMWdZX/1QB8ApeGgEBAQECAQEBAQgBAQEBgzkBAQEBAYFxB40sqQqCD4IDgmeDNgKBaRQBAgEBAQEBAQEDgQKEYQEBAQECATo/DAQCAQgRBAEBAR4JBzIUCQgCBA4FCAwHiCfAIQEBAQEBAQEBAQEBAQEBAQEBAQEBARyGMIRQhAkKEAIBhXcFiCqHPIQthVCPRYF1hGCJFIxVg3sehRFwhFWBIH8BAQE X-IPAS-Result: A2FPAQCMWdZX/1QB8ApeGgEBAQECAQEBAQgBAQEBgzkBAQEBAYFxB40sqQqCD4IDgmeDNgKBaRQBAgEBAQEBAQEDgQKEYQEBAQECATo/DAQCAQgRBAEBAR4JBzIUCQgCBA4FCAwHiCfAIQEBAQEBAQEBAQEBAQEBAQEBAQEBARyGMIRQhAkKEAIBhXcFiCqHPIQthVCPRYF1hGCJFIxVg3sehRFwhFWBIH8BAQE Received: from cph-gen-exch02.napatech.com (10.240.1.84) by cph-gen-exch02.napatech.com (10.240.1.84) with Microsoft SMTP Server (TLS) id 15.1.396.30; Mon, 12 Sep 2016 09:34:21 +0200 Received: from cph-gen-exch02.napatech.com ([fe80::581:51a1:ac3f:84e]) by cph-gen-exch02.napatech.com ([fe80::581:51a1:ac3f:84e%12]) with mapi id 15.01.0396.030; Mon, 12 Sep 2016 09:34:21 +0200 From: Finn Christensen To: Thomas Monjalon CC: Neil Horman , "dev@dpdk.org" , "stephen@networkplumber.org" Thread-Topic: [PATCH v3] ntnic: add PMD driver Thread-Index: AQHSCpjTzYbwHLfWUk6/dlutQqK7kqBxC7UAgAFDdiD///JiAIADMaZw Date: Mon, 12 Sep 2016 07:34:21 +0000 Message-ID: <9b58ce3a52404addaa2f1d972f345097@napatech.com> References: <20160908111424.14127-1-fc@napatech.com> <20160909135108.GA15908@hmsreliant.think-freely.org> <1913786.NX7M2nQ5WY@xps13> In-Reply-To: <1913786.NX7M2nQ5WY@xps13> Accept-Language: da-DK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.240.10.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 12 Sep 2016 07:34:24 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: 10. september 2016 10:20 > To: Finn Christensen > Cc: Neil Horman ; 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 > > > > --- > > > > 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 proble= m 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 follow= s the > NIC itself. > > > > In regards to the DPDK functionality we do not see that anything is mis= sing. > > 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 o= nly 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 yo= ur > 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 respe= ct 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 co= nclusion. 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 goo= d 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 D= PDK. Thanks for this discussion! Disclaimer: This email and any files transmitted with it may contain confid= ential information intended for the addressee(s) only. The information is n= ot to be surrendered or copied to unauthorized persons. If you have receive= d this communication in error, please notify the sender immediately and del= ete this e-mail from your system.