Re: [dpdk-dev] [dpdk-techboard] Napatech pmd

[Neil Horman <nhorman@tuxdriver.com>]

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
> > > <thomas@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"
> > > 
> > 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
>