On Tue, 09 Jan 2018 21:36:03 +0100 Thomas Monjalon <tho...@monjalon.net> 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" Though I suspect that DPDK linked to proprietary code is going to unmaintainable across releases, and very hard to debug problems.
