From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <prvs=1269554c0=fc@napatech.com> Received: from mail02.napatech.com (mail02.napatech.com [91.102.88.21]) by dpdk.org (Postfix) with ESMTP id 554FE2BAC for <dev@dpdk.org>; Mon, 21 Nov 2016 14:55:07 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EYAgBM/DJY/1QB8ApdGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzgBAQEBAXeBAAeNOJcSkXsXToIOggUkgXRTgzYCgj0UAQIBAQEBAQE?= =?us-ascii?q?BA4EHgwwbAQEBAQEBAQEBAQEBAQEBAQEBAQEBARUqAggFIjsBAQEBAzo/DAQCA?= =?us-ascii?q?QgRBAEBAR4JBzIUCQgCBAENBQgMB7IgDoNEi08BAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEchjyEWoQRChACAYV8BYhQFodGiiGGQoougXdPhCiJQI1fhAsegRU0hUFyh?= =?us-ascii?q?iSBIYEMAQEB?= X-IPAS-Result: =?us-ascii?q?A2EYAgBM/DJY/1QB8ApdGgEBAQECAQEBAQgBAQEBgzgBAQE?= =?us-ascii?q?BAXeBAAeNOJcSkXsXToIOggUkgXRTgzYCgj0UAQIBAQEBAQEBA4EHgwwbAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARUqAggFIjsBAQEBAzo/DAQCAQgRBAEBAR4JBzI?= =?us-ascii?q?UCQgCBAENBQgMB7IgDoNEi08BAQEBAQEBAQEBAQEBAQEBAQEBAQEchjyEWoQRC?= =?us-ascii?q?hACAYV8BYhQFodGiiGGQoougXdPhCiJQI1fhAsegRU0hUFyhiSBIYEMAQEB?= 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.466.34; Mon, 21 Nov 2016 14:55:05 +0100 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.0466.034; Mon, 21 Nov 2016 14:55:05 +0100 From: Finn Christensen <fc@napatech.com> To: Ferruh Yigit <ferruh.yigit@intel.com>, Thomas Monjalon <thomas.monjalon@6wind.com> CC: Neil Horman <nhorman@tuxdriver.com>, "dev@dpdk.org" <dev@dpdk.org>, "stephen@networkplumber.org" <stephen@networkplumber.org> Thread-Topic: [dpdk-dev] [PATCH v3] ntnic: add PMD driver Thread-Index: AQHSCpjTzYbwHLfWUk6/dlutQqK7kqBxC7UAgAFDdiD///JiAIADMaZwgG5igoCAABKT4A== Date: Mon, 21 Nov 2016 13:55:05 +0000 Message-ID: <88c39981c9ea43449ca6bb01659d3de6@napatech.com> References: <20160908111424.14127-1-fc@napatech.com> <20160909135108.GA15908@hmsreliant.think-freely.org> <c5e8998f3e0d4a8e9a26b6457193795e@napatech.com> <1913786.NX7M2nQ5WY@xps13> <9b58ce3a52404addaa2f1d972f345097@napatech.com> <bb63f27f-2cbd-7326-3118-f18b53dbad64@intel.com> In-Reply-To: <bb63f27f-2cbd-7326-3118-f18b53dbad64@intel.com> Accept-Language: da-DK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.240.10.132] 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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 21 Nov 2016 13:55:07 -0000 I have changed the state to rejected. Sorry for not doing this earlier. Finn Christensen -----Original Message----- From: Ferruh Yigit [mailto:ferruh.yigit@intel.com] Sent: 21. november 2016 14:48 To: Finn Christensen <fc@napatech.com>; Thomas Monjalon <thomas.monjalon@6w= ind.com> Cc: Neil Horman <nhorman@tuxdriver.com>; dev@dpdk.org; stephen@networkplumb= er.org Subject: Re: [dpdk-dev] [PATCH v3] ntnic: add PMD driver 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 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 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, u= ntil 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 gui= de, 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 libr= aries. > 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 func= tionality 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? 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.