From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Lilja Subject: Re: Napatech pmd Date: Tue, 9 Jan 2018 19:57:50 +0000 Message-ID: <82be0f1b54b543ed8f7bf0799512b1cd@napatech.com> References: <1643500.LyBOxPcb61@xps> <20180109185037.GB14094@hmswarspite.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: Finn Christensen , Neil Horman , Thomas Monjalon To: "dev@dpdk.org" Return-path: Received: from mail02.napatech.com (mail02.napatech.com [188.120.77.119]) by dpdk.org (Postfix) with ESMTP id 1E4831B20F for ; Tue, 9 Jan 2018 20:58:08 +0100 (CET) In-Reply-To: <20180109185037.GB14094@hmswarspite.think-freely.org> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > 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 tas= k > 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. > > >=20 > I have to ask the question: Why not open source your FPGA code? That > would make all of this a non issue. >=20 > 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 ha= ve > 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 responsibilit= y > for it as the license owner, but if that chages in the future, the PMD ha= s > 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. >=20 > Neil I understand your concern, but it is quite normal that BSP (Board Support P= ackage) is binary and has an API that is BSD licensed. The Napatech Suite i= s basically a BSP. The API that will be used in the PMD is a BSD licensed A= PI and so will the PMD be. If you understand the API you will be able to co= ntrol 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 s= tack and BSP packages free of charge to do Android development. /Michael