From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 3BDD11B16F; Wed, 10 Jan 2018 13:29:13 +0100 (CET) Received: from cpe-2606-a000-111b-423c-e874-da8e-c543-d863.dyn6.twc.com ([2606:a000:111b:423c:e874:da8e:c543:d863] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1eZFUv-000075-Pn; Wed, 10 Jan 2018 07:28:57 -0500 Date: Wed, 10 Jan 2018 07:28:15 -0500 From: Neil Horman To: Bruce Richardson Cc: Stephen Hemminger , Thomas Monjalon , Michael Lilja , dev@dpdk.org, Finn Christensen , techboard@dpdk.org Message-ID: <20180110122815.GA17772@hmswarspite.think-freely.org> References: <82be0f1b54b543ed8f7bf0799512b1cd@napatech.com> <20180109202006.GC14094@hmswarspite.think-freely.org> <13910919.17qZyt7zlq@xps> <20180109132129.09c40f0d@xeon-e3> <20180110002445.GB8523@hmswarspite.think-freely.org> <20180110102106.GB6388@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180110102106.GB6388@bricha3-MOBL3.ger.corp.intel.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [dpdk-techboard] Napatech pmd X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 12:29:13 -0000 On Wed, Jan 10, 2018 at 10:21:06AM +0000, Bruce Richardson wrote: > On Tue, Jan 09, 2018 at 07:24:45PM -0500, Neil Horman wrote: > > On Tue, Jan 09, 2018 at 01:21:29PM -0800, Stephen Hemminger wrote: > > > On Tue, 09 Jan 2018 21:36:03 +0100 Thomas Monjalon > > > wrote: > > > > > > > 09/01/2018 21:20, Neil Horman: > > > > > On Tue, Jan 09, 2018 at 07:57:50PM +0000, Michael Lilja wrote: > > > > > > > On Mon, Jan 08, 2018 at 04:15:47PM +0100, Thomas Monjalon > > > > > > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > 08/01/2018 14:08, Finn Christensen: > > > > > > > > > Hi Thomas, > > > > > > > > > > > > > > > > > > Thanks for bringing this discussion up again. > > > > > > > > > > > > > > > > > > The Napatech PMD is build on top of our proprietary > > > > > > > > > driver. The > > > > > > > reason is basically that we utilize many years of driver > > > > > > > development and thus reuses the FPGA controlling code in the > > > > > > > DPDK PMD. The Napatech driver suite is still closed source. > > > > > > > > > The current NTNIC PMD dynamically links a Napatech > > > > > > > > > proprietary > > > > > > > NTAPI library to control the FPGA on our NICs. > > > > > > > > > > > > > > > > > > We did think of the PMD as being our responsibility to > > > > > > > > > keep updated > > > > > > > towards the Napatech NIC communication, and that we would be > > > > > > > engaged and asked to modify accordingly if changes in DPDK > > > > > > > required that (maintainer). Furthermore, the PMD compiles > > > > > > > with no issues, when NTNIC is enabled. > > > > > > > > > We have plans to write a stand-alone PMD, but this is > > > > > > > > > not a small task > > > > > > > to do, therefore we haven't got to that yet. > > > > > > > > > > > > > > > > This standalone PMD would be open and BSD licensed? > > > > > > > > > > > > > > > > > If the DPDK community would accept the dynamic linking > > > > > > > > > to a > > > > > > > proprietary library, from inside our PMD, then it would be > > > > > > > great. > > > > > > > > > > > > > > > > Dynamic linking is OK. I think we can accept such PMD at > > > > > > > > the condition that we can build it, meaning we can easily > > > > > > > > download the build dependencies for free. > > > > > > > > > > > > > > > > > Let me know what you think. Or maybe you have ideas to > > > > > > > > > what else > > > > > > > we could do to make it upstream. > > > > > > > > > > > > > > > > My thinking is to allow every hardware to have a good DPDK > > > > > > > > support. Every step in this direction is a progress. > > > > > > > > > > > > > > > > > > > > > > I have to ask the question: Why not open source your FPGA > > > > > > > code? That would make all of this a non issue. > > > > > > > > > > > > > > While I knows it to various degrees been done in the past, I > > > > > > > really don't like the idea of including drivers (even open > > > > > > > source drivers), if they have dependencies on closed source > > > > > > > software. It means that we as a community assume some level > > > > > > > of responsibility for that pmd, but have no ability to make > > > > > > > fixes to that pmd without accepting your license terms. I > > > > > > > understand that you are saying you currently have > > > > > > > responsibility for it as the license owner, but if that > > > > > > > chages in the future, the PMD has no use to the community. > > > > > > > It would be preferable if access to controlling the hardware > > > > > > > was just free of a proprietary license. Then you wouldn't > > > > > > > have to write a stand alone pmd. > > > > > > > > > > > > > > Neil > > > > > > I understand your concern, but it is quite normal that BSP > > > > > > (Board Support Package) is binary and has an API that is BSD > > > > > > licensed. The Napatech Suite is basically a BSP. The API that > > > > > > will be used in the PMD is a BSD licensed API and so will the > > > > > > PMD be. If you understand the API you will be able to control > > > > > > the hardware and thereby also be able to change the DPDK > > > > > > driver. The API is public available and so is the BSP binary > > > > > > package. A good analogy is how Android does open source > > > > > > develop for Quallcomm based HW boards, where the Quallcomm > > > > > > firmware is proprietary. Any user can download full Android > > > > > > stack and BSP packages free of charge to do Android > > > > > > development. > > > > > > > > > > > > /Michael > > > > > > > > > > > You can couch it any way you like, but regardless of how you > > > > > want to view the proprietary part of this system, the hardware > > > > > is being used as a NIC in the DPDK, and for that purpose you > > > > > need a driver. As you currently have it architected, the driver > > > > > (open source or not), is useless without the binary portion > > > > > underneath it, and so is useless to any user without agreeing to > > > > > your license terms. Pert of the benefit of open source software > > > > > is that users can continue to modify/enchance/maintain the > > > > > software powering your hardware after you decide to stop > > > > > supporting it. And so I'm not comfortable with accepting code > > > > > that doesn't allow this community to do that. > > > > > > > > > > Neil > > > > > > > > How different is it of having a proprietary firmware? > > > > > > > > I think it is better for the Napatech users to have this PMD > > > > supported upstream. If it is too complicate to maintain and not > > > > supported by Napatech, we are free to drop it. > > > > > > > > Adding the technical board Cc. > > > > > > > > > Agree with Thomas. "Bad breath is better than no breath at all" > > > > > I understand your intent here, but in fairness, theres a position > > between bad and no breath, metaphorically - that is to say, > > maintaining the driver out of tree. > > > > > Though I suspect that DPDK linked to proprietary code is going to > > > unmaintainable across releases, and very hard to debug problems. > > > > > My point exactly, this PMD will receive exactly no testing from anyone > > in the community as they won't accept the license terms of the binary > > blob underneath it, and so this driver will likely see almost exactly > > the same level of support as it would were it maintained out of tree. > > > I wonder is this really an issue? For many NIC drivers, now many > community users actively test (not just use in their app, but test a > full range of functions) the driver, apart from the maintainers from the > NIC vendors? [Thinking here especially of the less commonly used ones]. > > So long as there is active maintenance of the driver by the vendor, I > don't think there is a problem. Once code is unmaintained, it *is* a > problem, whether the underlying requirements are proprietary or not - > just look at Xen support in DPDK! In my view, by accepting a driver > with a proprietary dependency, the only thing we are lacking is the > ability for someone else to step up to maintain the driver should the > original vendor drop out. Given our difficulty in finding maintainers > for things, I wouldn't view that as a major loss. > I can see I'm in the minority on this issue, and thats fine, Just please understand that, in my experience, this has never gone well in the past in any community I have participated in. Neil > Regards, > /Bruce >