10/01/2018 01:19, Neil Horman: > On Tue, Jan 09, 2018 at 09:36:03PM +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? > > > Significantly in the sense that firmware ships burned or pre-programmed into > the > hardware in such a way that the user isn't required to accept a EULA to use > it. > The I40e card for example has a closed firmware, but when you buy a card, the > firmware is pre-installed as part of the device, you dont need to accept > additional terms of use prior to the device being functional with the open > source driver. > > > I think it is better for the Napatech users to have this PMD > > supported upstream. > But you can't support it upstream. The Napatech folks can (and for that I'm > appreciative), but should they decide to stop supporting it, or otherwise make > their FPGA library unavailable, anyone outside of Napatech is left unable to > do > anything with it. It becomes inert. > > > If it is too complicate to maintain and not supported by Napatech, > > we are free to drop it. > I agree, but again, its not "us" as in the community supporing it. If it were > truly open source, Napatech could decide to discontinue support tomorrow, and > we > could pick up where they left off. As it currently stands We're just acting > as > a repository for Napatechs code. > > I understand this is likely to happen anyway, and if it does, so be it, I just > need to voice my concern here.
I don't know whether it will happen or not, that's why it's good to discuss and express our opinions (thanks). > > Adding the technical board Cc. Now we should get a decision from the technical board.
