[dpdk-dev] Napatech pmd

[dpdk-dev] Napatech pmd

[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.

If the DPDK community would accept the dynamic linking to a proprietary library, from inside our PMD, then it would be great.

Let me know what you think. Or maybe you have ideas to what else we could do to make it upstream.

Thanks,
Finn


>-----Original Message-----
>From: Thomas Monjalon [mailto:thomas@monjalon.net]
>Sent: 5. januar 2018 16:34
>To: Finn Christensen <fc@napatech.com>
>Subject: Re: [dpdk-dev] standardize device identification
>
>It leads to a totally different question:
>Can we discuss again how to integrate your driver in DPDK upstream?
>Please explain again your situation in a new thread.

Re: [dpdk-dev] Napatech pmd

[Thomas Monjalon]

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.

Re: [dpdk-dev] Napatech pmd

[Stephen Hemminger]

On Mon, 08 Jan 2018 16:15:47 +0100
Thomas Monjalon <thomas@monjalon.net> 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.

Also the API to the proprietary code must be separate from DPDK headers.
Ideally the ABI for DPDK could evolve and the vendor code would not need to be updated.

Re: [dpdk-dev] Napatech pmd

[Finn Christensen]

>-----Original Message-----
>From: Thomas Monjalon [mailto:thomas@monjalon.net]
>Sent: 8. januar 2018 16:16
>To: Finn Christensen <fc@napatech.com>
>Cc: dev@dpdk.org
>Subject: Re: [dpdk-dev] Napatech pmd
>
>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?

Yes!

>
>> 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.

That sounds great. This was also our initial thoughts about the implementation.
I will try to start this task up again and next step, I guess, will be a new RFC for a
new Napatech pmd.

>
>> 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.

Thanks,
Finn

Re: [dpdk-dev] Napatech pmd

[Neil Horman]

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

Re: [dpdk-dev] Napatech pmd

[Michael Lilja]

> 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

Re: [dpdk-dev] Napatech pmd

[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

> 
> 
> Disclaimer: This email and any files transmitted with it may contain confidential information intended for the addressee(s) only. The information is not to be surrendered or copied to unauthorized persons. If you have received this communication in error, please notify the sender immediately and delete this e-mail from your system.
> 

Re: [dpdk-dev] Napatech pmd

[Thomas Monjalon]

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.

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

[Stephen Hemminger]

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"

Though I suspect that DPDK linked to proprietary code is going to unmaintainable
across releases, and very hard to debug problems. 

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

[Neil Horman]

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.

Neil

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

[Bruce Richardson]

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.

Regards,
/Bruce

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

[Neil Horman]

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
> 

Re: [dpdk-dev] Napatech pmd

[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.

Neil

> 
> Adding the technical board Cc.
> 

Re: [dpdk-dev] Napatech pmd

[Thomas Monjalon]

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.

Re: [dpdk-dev] Napatech pmd

[Thomas Monjalon]

Hi,

Raising this topic again.

As said in the past, it is better to have this PMD inside DPDK.
We discussed some concerns, but I think the consensus was to integrate
Napatech PMD anyway.

I am sad that you did not feel welcome enough to follow up with patches
during all these years.
Please would you like to restart the upstreaming process?


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.
> 
> If the DPDK community would accept the dynamic linking to a proprietary library, from inside our PMD, then it would be great.
> 
> Let me know what you think. Or maybe you have ideas to what else we could do to make it upstream.
> 
> Thanks,
> Finn
> 
> 
> >-----Original Message-----
> >From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >Sent: 5. januar 2018 16:34
> >To: Finn Christensen <fc@napatech.com>
> >Subject: Re: [dpdk-dev] standardize device identification
> >
> >It leads to a totally different question:
> >Can we discuss again how to integrate your driver in DPDK upstream?
> >Please explain again your situation in a new thread.
> 

Re: [dpdk-dev] Napatech pmd

[Neil Horman]

On Tue, Mar 31, 2020 at 01:25:25PM +0200, Thomas Monjalon wrote:
> Hi,
> 
> Raising this topic again.
> 
> As said in the past, it is better to have this PMD inside DPDK.
> We discussed some concerns, but I think the consensus was to integrate
> Napatech PMD anyway.
> 
> I am sad that you did not feel welcome enough to follow up with patches
> during all these years.
> Please would you like to restart the upstreaming process?
> 
Whats changed here?

I still don't see what the advantage is to accepting this code in the DPDK tree.
No one will be able to use it without accepting Napatechs license for their
underlying library.  As such, the code can't really be maintained at all by
anyone other than Napatech in the community, and so may as well just be
maintained as an out of tree driver.

Neil

> 
> 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.
> > 
> > If the DPDK community would accept the dynamic linking to a proprietary library, from inside our PMD, then it would be great.
> > 
> > Let me know what you think. Or maybe you have ideas to what else we could do to make it upstream.
> > 
> > Thanks,
> > Finn
> > 
> > 
> > >-----Original Message-----
> > >From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > >Sent: 5. januar 2018 16:34
> > >To: Finn Christensen <fc@napatech.com>
> > >Subject: Re: [dpdk-dev] standardize device identification
> > >
> > >It leads to a totally different question:
> > >Can we discuss again how to integrate your driver in DPDK upstream?
> > >Please explain again your situation in a new thread.
> > 
> 
> 
> 
> 
> 
> 

Re: [dpdk-dev] Napatech pmd

[Thomas Monjalon]

31/03/2020 14:17, Neil Horman:
> On Tue, Mar 31, 2020 at 01:25:25PM +0200, Thomas Monjalon wrote:
> > Hi,
> > 
> > Raising this topic again.
> > 
> > As said in the past, it is better to have this PMD inside DPDK.
> > We discussed some concerns, but I think the consensus was to integrate
> > Napatech PMD anyway.
> > 
> > I am sad that you did not feel welcome enough to follow up with patches
> > during all these years.
> > Please would you like to restart the upstreaming process?
> > 
> Whats changed here?

Nothing changed, except years.

> I still don't see what the advantage is to accepting this code in the DPDK tree.
> No one will be able to use it without accepting Napatechs license for their
> underlying library.  As such, the code can't really be maintained at all by
> anyone other than Napatech in the community, and so may as well just be
> maintained as an out of tree driver.

You are the only one having this concern.
Nobody from the Technical Board looks to be against the acceptance.

The advantage is simple: Napatech customers will be able to run any DPDK version.


> > 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.
> > > 
> > > If the DPDK community would accept the dynamic linking to a proprietary library, from inside our PMD, then it would be great.
> > > 
> > > Let me know what you think. Or maybe you have ideas to what else we could do to make it upstream.
> > > 
> > > Thanks,
> > > Finn
> > > 
> > > 
> > > >-----Original Message-----
> > > >From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > >Sent: 5. januar 2018 16:34
> > > >To: Finn Christensen <fc@napatech.com>
> > > >Subject: Re: [dpdk-dev] standardize device identification
> > > >
> > > >It leads to a totally different question:
> > > >Can we discuss again how to integrate your driver in DPDK upstream?
> > > >Please explain again your situation in a new thread.
> > > 
> > 
> > 
> > 
> > 
> > 
> > 
> 

Re: [dpdk-dev] Napatech pmd

[Michael Lilja]

Hi,

I appreciate the discussion. It would of course be nice if vendors could be allowed to use external libraries/drivers and have a DPDK shim but I also understand the concern.

We have started the movement towards an open source variant of our NICs driver so that upstreaming to DPDK (and kernel) will be possible. The downside is that not all NICs will be supported, it is simply not worth the effort rewriting a legacy codebase.

Thanks,
Michael

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: 31. marts 2020 14:29
> To: Neil Horman <nhorman@tuxdriver.com>
> Cc: Finn Christensen <fc@napatech.com>; dev@dpdk.org; Bent Kuhre
> <bk@napatech.com>; Michael Lilja <ml@napatech.com>; techboard@dpdk.org
> Subject: Re: [dpdk-dev] Napatech pmd
> 
> 31/03/2020 14:17, Neil Horman:
> > On Tue, Mar 31, 2020 at 01:25:25PM +0200, Thomas Monjalon wrote:
> > > Hi,
> > >
> > > Raising this topic again.
> > >
> > > As said in the past, it is better to have this PMD inside DPDK.
> > > We discussed some concerns, but I think the consensus was to
> > > integrate Napatech PMD anyway.
> > >
> > > I am sad that you did not feel welcome enough to follow up with
> > > patches during all these years.
> > > Please would you like to restart the upstreaming process?
> > >
> > Whats changed here?
> 
> Nothing changed, except years.
> 
> > I still don't see what the advantage is to accepting this code in
> the DPDK tree.
> > No one will be able to use it without accepting Napatechs license
> for
> > their underlying library.  As such, the code can't really be
> > maintained at all by anyone other than Napatech in the community,
> and
> > so may as well just be maintained as an out of tree driver.
> 
> You are the only one having this concern.
> Nobody from the Technical Board looks to be against the acceptance.
> 
> The advantage is simple: Napatech customers will be able to run any
> DPDK version.
> 
> 
> > > 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.
> > > >
> > > > If the DPDK community would accept the dynamic linking to a
> proprietary library, from inside our PMD, then it would be great.
> > > >
> > > > Let me know what you think. Or maybe you have ideas to what else
> we could do to make it upstream.
> > > >
> > > > Thanks,
> > > > Finn
> > > >
> > > >
> > > > >-----Original Message-----
> > > > >From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > >Sent: 5. januar 2018 16:34
> > > > >To: Finn Christensen <fc@napatech.com>
> > > > >Subject: Re: [dpdk-dev] standardize device identification
> > > > >
> > > > >It leads to a totally different question:
> > > > >Can we discuss again how to integrate your driver in DPDK
> upstream?
> > > > >Please explain again your situation in a new thread.
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> 
> 
> 
> 

Re: [dpdk-dev] Napatech pmd

[Thomas Monjalon]

31/03/2020 14:39, Michael Lilja:
> Hi,
> 
> I appreciate the discussion. It would of course be nice if vendors could be allowed to use external libraries/drivers and have a DPDK shim but I also understand the concern.
> 
> We have started the movement towards an open source variant of our NICs driver so that upstreaming to DPDK (and kernel) will be possible. The downside is that not all NICs will be supported, it is simply not worth the effort rewriting a legacy codebase.

That's a very good news!
When do you plan to start upstreaming?

Re: [dpdk-dev] Napatech pmd

[Michael Lilja]

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: 31. marts 2020 14:45
> To: Michael Lilja <ml@napatech.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>; Finn Christensen
> <fc@napatech.com>; dev@dpdk.org; Bent Kuhre <bk@napatech.com>
> Subject: Re: [dpdk-dev] Napatech pmd
> 
> 31/03/2020 14:39, Michael Lilja:
> > Hi,
> >
> > I appreciate the discussion. It would of course be nice if vendors
> could be allowed to use external libraries/drivers and have a DPDK
> shim but I also understand the concern.
> >
> > We have started the movement towards an open source variant of our
> NICs driver so that upstreaming to DPDK (and kernel) will be possible.
> The downside is that not all NICs will be supported, it is simply not
> worth the effort rewriting a legacy codebase.
> 
> That's a very good news!
> When do you plan to start upstreaming?

That is a good question... Soon hopefully, it is a work in progress :D

> 
> 

Re: [dpdk-dev] Napatech pmd

[Stephen Hemminger]

On Tue, 31 Mar 2020 12:39:17 +0000
Michael Lilja <ml@napatech.com> wrote:

> Hi,
> 
> I appreciate the discussion. It would of course be nice if vendors could be allowed to use external libraries/drivers and have a DPDK shim but I also understand the concern.
> 
> We have started the movement towards an open source variant of our NICs driver so that upstreaming to DPDK (and kernel) will be possible. The downside is that not all NICs will be supported, it is simply not worth the effort rewriting a legacy codebase.
> 
> Thanks,
> Michael

The downside is that any proprietary requirement means code is untestable by
any CI or infrastructure. Therefore it is likely to be broken.

Re: [dpdk-dev] Napatech pmd

[Neil Horman]

On Tue, Mar 31, 2020 at 07:58:45AM -0700, Stephen Hemminger wrote:
> On Tue, 31 Mar 2020 12:39:17 +0000
> Michael Lilja <ml@napatech.com> wrote:
> 
> > Hi,
> > 
> > I appreciate the discussion. It would of course be nice if vendors could be allowed to use external libraries/drivers and have a DPDK shim but I also understand the concern.
> > 
> > We have started the movement towards an open source variant of our NICs driver so that upstreaming to DPDK (and kernel) will be possible. The downside is that not all NICs will be supported, it is simply not worth the effort rewriting a legacy codebase.
> > 
> > Thanks,
> > Michael
> 
> The downside is that any proprietary requirement means code is untestable by
> any CI or infrastructure. Therefore it is likely to be broken.
> 

This.  This is exactly my concern.  Because the Napatech PMD is really just an
interface to some proprietary code, no one outside of Napatech will have any
insight or ability to test (or use) it.

Re: [dpdk-dev] Napatech pmd

[Thomas Monjalon]

31/03/2020 21:51, Neil Horman:
> On Tue, Mar 31, 2020 at 07:58:45AM -0700, Stephen Hemminger wrote:
> > On Tue, 31 Mar 2020 12:39:17 +0000
> > Michael Lilja <ml@napatech.com> wrote:
> > 
> > > Hi,
> > > 
> > > I appreciate the discussion. It would of course be nice if vendors could be allowed to use external libraries/drivers and have a DPDK shim but I also understand the concern.
> > > 
> > > We have started the movement towards an open source variant of our NICs driver so that upstreaming to DPDK (and kernel) will be possible. The downside is that not all NICs will be supported, it is simply not worth the effort rewriting a legacy codebase.
> > > 
> > > Thanks,
> > > Michael
> > 
> > The downside is that any proprietary requirement means code is untestable by
> > any CI or infrastructure. Therefore it is likely to be broken.
> > 
> 
> This.  This is exactly my concern.  Because the Napatech PMD is really just an
> interface to some proprietary code, no one outside of Napatech will have any
> insight or ability to test (or use) it.

Michael just said above they are writing an open source driver.
Please encourage this great move.

Re: [dpdk-dev] Napatech pmd

[Neil Horman]

On Tue, Mar 31, 2020 at 09:59:27PM +0200, Thomas Monjalon wrote:
> 31/03/2020 21:51, Neil Horman:
> > On Tue, Mar 31, 2020 at 07:58:45AM -0700, Stephen Hemminger wrote:
> > > On Tue, 31 Mar 2020 12:39:17 +0000
> > > Michael Lilja <ml@napatech.com> wrote:
> > > 
> > > > Hi,
> > > > 
> > > > I appreciate the discussion. It would of course be nice if vendors could be allowed to use external libraries/drivers and have a DPDK shim but I also understand the concern.
> > > > 
> > > > We have started the movement towards an open source variant of our NICs driver so that upstreaming to DPDK (and kernel) will be possible. The downside is that not all NICs will be supported, it is simply not worth the effort rewriting a legacy codebase.
> > > > 
> > > > Thanks,
> > > > Michael
> > > 
> > > The downside is that any proprietary requirement means code is untestable by
> > > any CI or infrastructure. Therefore it is likely to be broken.
> > > 
> > 
> > This.  This is exactly my concern.  Because the Napatech PMD is really just an
> > interface to some proprietary code, no one outside of Napatech will have any
> > insight or ability to test (or use) it.
> 
> Michael just said above they are writing an open source driver.
> Please encourage this great move.
> 
Its a great move, sure, but it was a great move back in september of 2016 too:
https://mails.dpdk.org/archives/dev/2016-September/046522.html


I don't see any progress in that direction, and I don't see how allowing a
driver that needs closed source underpinnings encourages progress on that front.

Is there a git tree of the open source driver somewhere that we can review?  I'd
be happy to look at integrating that driver, even if its in an incomplete state,
as an encouraging step to complete that work.

Neil
 

Re: [dpdk-dev] Napatech pmd

[Neil Horman]

On Tue, Mar 31, 2020 at 02:29:08PM +0200, Thomas Monjalon wrote:
> 31/03/2020 14:17, Neil Horman:
> > On Tue, Mar 31, 2020 at 01:25:25PM +0200, Thomas Monjalon wrote:
> > > Hi,
> > > 
> > > Raising this topic again.
> > > 
> > > As said in the past, it is better to have this PMD inside DPDK.
> > > We discussed some concerns, but I think the consensus was to integrate
> > > Napatech PMD anyway.
> > > 
> > > I am sad that you did not feel welcome enough to follow up with patches
> > > during all these years.
> > > Please would you like to restart the upstreaming process?
> > > 
> > Whats changed here?
> 
> Nothing changed, except years.
> 
> > I still don't see what the advantage is to accepting this code in the DPDK tree.
> > No one will be able to use it without accepting Napatechs license for their
> > underlying library.  As such, the code can't really be maintained at all by
> > anyone other than Napatech in the community, and so may as well just be
> > maintained as an out of tree driver.
> 
> You are the only one having this concern.
I don't think its wise to assume that silence implies acceptance.

> Nobody from the Technical Board looks to be against the acceptance.
> 
> The advantage is simple: Napatech customers will be able to run any DPDK version.
Why is that not possible by having napatech maintain an out-of-tree PMD?  Theres
no reason that can't be done.

Neil

> 
> 
> > > 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.
> > > > 
> > > > If the DPDK community would accept the dynamic linking to a proprietary library, from inside our PMD, then it would be great.
> > > > 
> > > > Let me know what you think. Or maybe you have ideas to what else we could do to make it upstream.
> > > > 
> > > > Thanks,
> > > > Finn
> > > > 
> > > > 
> > > > >-----Original Message-----
> > > > >From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > >Sent: 5. januar 2018 16:34
> > > > >To: Finn Christensen <fc@napatech.com>
> > > > >Subject: Re: [dpdk-dev] standardize device identification
> > > > >
> > > > >It leads to a totally different question:
> > > > >Can we discuss again how to integrate your driver in DPDK upstream?
> > > > >Please explain again your situation in a new thread.
> > > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> 
> 
> 
> 
> 
> 

Re: [dpdk-dev] Napatech pmd

[Thomas Monjalon]

31/03/2020 21:56, Neil Horman:
> On Tue, Mar 31, 2020 at 02:29:08PM +0200, Thomas Monjalon wrote:
> > 31/03/2020 14:17, Neil Horman:
> > > On Tue, Mar 31, 2020 at 01:25:25PM +0200, Thomas Monjalon wrote:
> > > > Hi,
> > > > 
> > > > Raising this topic again.
> > > > 
> > > > As said in the past, it is better to have this PMD inside DPDK.
> > > > We discussed some concerns, but I think the consensus was to integrate
> > > > Napatech PMD anyway.
> > > > 
> > > > I am sad that you did not feel welcome enough to follow up with patches
> > > > during all these years.
> > > > Please would you like to restart the upstreaming process?
> > > > 
> > > Whats changed here?
> > 
> > Nothing changed, except years.
> > 
> > > I still don't see what the advantage is to accepting this code in the DPDK tree.
> > > No one will be able to use it without accepting Napatechs license for their
> > > underlying library.  As such, the code can't really be maintained at all by
> > > anyone other than Napatech in the community, and so may as well just be
> > > maintained as an out of tree driver.
> > 
> > You are the only one having this concern.
> I don't think its wise to assume that silence implies acceptance.
> 
> > Nobody from the Technical Board looks to be against the acceptance.
> > 
> > The advantage is simple: Napatech customers will be able to run any DPDK version.
> Why is that not possible by having napatech maintain an out-of-tree PMD?  Theres
> no reason that can't be done.

They are maintaining an out-of-tree PMD:
	https://github.com/napatech/dpdk/releases

I'm just trying to improve the situation, avoiding DPDK forks.

Re: [dpdk-dev] Napatech pmd

[Neil Horman]

On Tue, Mar 31, 2020 at 10:07:12PM +0200, Thomas Monjalon wrote:
> 31/03/2020 21:56, Neil Horman:
> > On Tue, Mar 31, 2020 at 02:29:08PM +0200, Thomas Monjalon wrote:
> > > 31/03/2020 14:17, Neil Horman:
> > > > On Tue, Mar 31, 2020 at 01:25:25PM +0200, Thomas Monjalon wrote:
> > > > > Hi,
> > > > > 
> > > > > Raising this topic again.
> > > > > 
> > > > > As said in the past, it is better to have this PMD inside DPDK.
> > > > > We discussed some concerns, but I think the consensus was to integrate
> > > > > Napatech PMD anyway.
> > > > > 
> > > > > I am sad that you did not feel welcome enough to follow up with patches
> > > > > during all these years.
> > > > > Please would you like to restart the upstreaming process?
> > > > > 
> > > > Whats changed here?
> > > 
> > > Nothing changed, except years.
> > > 
> > > > I still don't see what the advantage is to accepting this code in the DPDK tree.
> > > > No one will be able to use it without accepting Napatechs license for their
> > > > underlying library.  As such, the code can't really be maintained at all by
> > > > anyone other than Napatech in the community, and so may as well just be
> > > > maintained as an out of tree driver.
> > > 
> > > You are the only one having this concern.
> > I don't think its wise to assume that silence implies acceptance.
> > 
> > > Nobody from the Technical Board looks to be against the acceptance.
> > > 
> > > The advantage is simple: Napatech customers will be able to run any DPDK version.
> > Why is that not possible by having napatech maintain an out-of-tree PMD?  Theres
> > no reason that can't be done.
> 
> They are maintaining an out-of-tree PMD:
> 	https://github.com/napatech/dpdk/releases
> 
> I'm just trying to improve the situation, avoiding DPDK forks.
The threat of forks is overstated.  No single vendor is going to throw the
resources needed to properly maintain the full dpdk release just so they can get
their one driver into the same tree.

Also, I'm not sure if this helps, but the approach being taken in the napatech
tree is fairly heavyweight.  Instead of cloning the entire dpdk tree, they could
just be maintaining the drivers/net/napatech directory, with build instructions
indicating that a user should clone and build dpdk, then build their tree, after
setting RTE_SDK/RTE_SRCDIR/etc appropriately.

Re: [dpdk-dev] Napatech pmd

[Neil Horman]

On Tue, Mar 31, 2020 at 10:07:12PM +0200, Thomas Monjalon wrote:
> 31/03/2020 21:56, Neil Horman:
> > On Tue, Mar 31, 2020 at 02:29:08PM +0200, Thomas Monjalon wrote:
> > > 31/03/2020 14:17, Neil Horman:
> > > > On Tue, Mar 31, 2020 at 01:25:25PM +0200, Thomas Monjalon wrote:
> > > > > Hi,
> > > > > 
> > > > > Raising this topic again.
> > > > > 
> > > > > As said in the past, it is better to have this PMD inside DPDK.
> > > > > We discussed some concerns, but I think the consensus was to integrate
> > > > > Napatech PMD anyway.
> > > > > 
> > > > > I am sad that you did not feel welcome enough to follow up with patches
> > > > > during all these years.
> > > > > Please would you like to restart the upstreaming process?
> > > > > 
> > > > Whats changed here?
> > > 
> > > Nothing changed, except years.
> > > 
> > > > I still don't see what the advantage is to accepting this code in the DPDK tree.
> > > > No one will be able to use it without accepting Napatechs license for their
> > > > underlying library.  As such, the code can't really be maintained at all by
> > > > anyone other than Napatech in the community, and so may as well just be
> > > > maintained as an out of tree driver.
> > > 
> > > You are the only one having this concern.
> > I don't think its wise to assume that silence implies acceptance.
> > 
> > > Nobody from the Technical Board looks to be against the acceptance.
> > > 
> > > The advantage is simple: Napatech customers will be able to run any DPDK version.
> > Why is that not possible by having napatech maintain an out-of-tree PMD?  Theres
> > no reason that can't be done.
> 
> They are maintaining an out-of-tree PMD:
> 	https://github.com/napatech/dpdk/releases
> 
> I'm just trying to improve the situation, avoiding DPDK forks.
> 
> 
> 
Apologies, I completely missed responding to this note

I took a look at the PMD above.  Its not an open source implementation
of their driver, its the same thing they offered 4 years ago, a skeleton
pmd that still uses the same closed licensed library.

It was my understanding that they were working on a completely open
sourced PMD that could be generally useful to the community.  If that
exists, then yes, by all means, lets take a look at it, and consider
merging it.  That effort deserves consideration.

This however, is the same thing we saw last time.  Theres no benefit in
including that

Neil

Re: [dpdk-dev] Napatech pmd

[Michael Lilja]

> -----Original Message-----
> From: Neil Horman <nhorman@tuxdriver.com>
> Sent: 17. april 2020 04:55
> To: Thomas Monjalon <thomas@monjalon.net>
> Cc: Finn Christensen <fc@napatech.com>; dev@dpdk.org; Bent Kuhre
> <bk@napatech.com>; Michael Lilja <ml@napatech.com>; techboard@dpdk.org
> Subject: Re: [dpdk-dev] Napatech pmd
> 
> On Tue, Mar 31, 2020 at 10:07:12PM +0200, Thomas Monjalon wrote:
> > 31/03/2020 21:56, Neil Horman:
> > > On Tue, Mar 31, 2020 at 02:29:08PM +0200, Thomas Monjalon wrote:
> > > > 31/03/2020 14:17, Neil Horman:
> > > > > On Tue, Mar 31, 2020 at 01:25:25PM +0200, Thomas Monjalon
> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Raising this topic again.
> > > > > >
> > > > > > As said in the past, it is better to have this PMD inside
> DPDK.
> > > > > > We discussed some concerns, but I think the consensus was to
> > > > > > integrate Napatech PMD anyway.
> > > > > >
> > > > > > I am sad that you did not feel welcome enough to follow up
> > > > > > with patches during all these years.
> > > > > > Please would you like to restart the upstreaming process?
> > > > > >
> > > > > Whats changed here?
> > > >
> > > > Nothing changed, except years.
> > > >
> > > > > I still don't see what the advantage is to accepting this code
> in the DPDK tree.
> > > > > No one will be able to use it without accepting Napatechs
> > > > > license for their underlying library.  As such, the code can't
> > > > > really be maintained at all by anyone other than Napatech in
> the
> > > > > community, and so may as well just be maintained as an out of
> tree driver.
> > > >
> > > > You are the only one having this concern.
> > > I don't think its wise to assume that silence implies acceptance.
> > >
> > > > Nobody from the Technical Board looks to be against the
> acceptance.
> > > >
> > > > The advantage is simple: Napatech customers will be able to run
> any DPDK version.
> > > Why is that not possible by having napatech maintain an out-of-
> tree
> > > PMD?  Theres no reason that can't be done.
> >
> > They are maintaining an out-of-tree PMD:
> > 	https://github.com/napatech/dpdk/releases
> >
> > I'm just trying to improve the situation, avoiding DPDK forks.
> >
> >
> >
> Apologies, I completely missed responding to this note
> 
> I took a look at the PMD above.  Its not an open source implementation
> of their driver, its the same thing they offered 4 years ago, a
> skeleton pmd that still uses the same closed licensed library.
> 
> It was my understanding that they were working on a completely open
> sourced PMD that could be generally useful to the community.  If that
> exists, then yes, by all means, lets take a look at it, and consider
> merging it.  That effort deserves consideration.
> 
> This however, is the same thing we saw last time.  Theres no benefit
> in including that
> 
> Neil
I understand the confusion. The PMD in our github is still, as you correctly state, based on our closed source driver and only a skeleton. We are working on a open source version, but currently that is WIP and not pushed yet. I'll let you know when there is something to look at.

Michael

Re: [dpdk-dev] Napatech pmd

[Neil Horman]

On Fri, Apr 17, 2020 at 04:38:42AM +0000, Michael Lilja wrote:
> > -----Original Message-----
> > From: Neil Horman <nhorman@tuxdriver.com>
> > Sent: 17. april 2020 04:55
> > To: Thomas Monjalon <thomas@monjalon.net>
> > Cc: Finn Christensen <fc@napatech.com>; dev@dpdk.org; Bent Kuhre
> > <bk@napatech.com>; Michael Lilja <ml@napatech.com>; techboard@dpdk.org
> > Subject: Re: [dpdk-dev] Napatech pmd
> >
> > On Tue, Mar 31, 2020 at 10:07:12PM +0200, Thomas Monjalon wrote:
> > > 31/03/2020 21:56, Neil Horman:
> > > > On Tue, Mar 31, 2020 at 02:29:08PM +0200, Thomas Monjalon wrote:
> > > > > 31/03/2020 14:17, Neil Horman:
> > > > > > On Tue, Mar 31, 2020 at 01:25:25PM +0200, Thomas Monjalon
> > wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Raising this topic again.
> > > > > > >
> > > > > > > As said in the past, it is better to have this PMD inside
> > DPDK.
> > > > > > > We discussed some concerns, but I think the consensus was to
> > > > > > > integrate Napatech PMD anyway.
> > > > > > >
> > > > > > > I am sad that you did not feel welcome enough to follow up
> > > > > > > with patches during all these years.
> > > > > > > Please would you like to restart the upstreaming process?
> > > > > > >
> > > > > > Whats changed here?
> > > > >
> > > > > Nothing changed, except years.
> > > > >
> > > > > > I still don't see what the advantage is to accepting this code
> > in the DPDK tree.
> > > > > > No one will be able to use it without accepting Napatechs
> > > > > > license for their underlying library.  As such, the code can't
> > > > > > really be maintained at all by anyone other than Napatech in
> > the
> > > > > > community, and so may as well just be maintained as an out of
> > tree driver.
> > > > >
> > > > > You are the only one having this concern.
> > > > I don't think its wise to assume that silence implies acceptance.
> > > >
> > > > > Nobody from the Technical Board looks to be against the
> > acceptance.
> > > > >
> > > > > The advantage is simple: Napatech customers will be able to run
> > any DPDK version.
> > > > Why is that not possible by having napatech maintain an out-of-
> > tree
> > > > PMD?  Theres no reason that can't be done.
> > >
> > > They are maintaining an out-of-tree PMD:
> > > https://github.com/napatech/dpdk/releases
> > >
> > > I'm just trying to improve the situation, avoiding DPDK forks.
> > >
> > >
> > >
> > Apologies, I completely missed responding to this note
> >
> > I took a look at the PMD above.  Its not an open source implementation
> > of their driver, its the same thing they offered 4 years ago, a
> > skeleton pmd that still uses the same closed licensed library.
> >
> > It was my understanding that they were working on a completely open
> > sourced PMD that could be generally useful to the community.  If that
> > exists, then yes, by all means, lets take a look at it, and consider
> > merging it.  That effort deserves consideration.
> >
> > This however, is the same thing we saw last time.  Theres no benefit
> > in including that
> >
> > Neil
> I understand the confusion. The PMD in our github is still, as you correctly state, based on our closed source driver and only a skeleton. We are working on a open source version, but currently that is WIP and not pushed yet. I'll let you know when there is something to look at.
> 

So, I have to ask.  I referenced this email from 2016 earlier in this
thread:
https://mails.dpdk.org/archives/dev/2016-September/046522.html

Where a colleague of yours from Napatech noted that you were working on
an fully open source driver.  Given that you have been working on this
to some degree since then, I would presume that you could share what
code you have thus far.  Can you place the code you have written thus
far in a public repository so we can start reviewing it?

Thanks
Neil
> Michael
> 
> Disclaimer: This email and any files transmitted with it may contain confidential information intended for the addressee(s) only. The information is not to be surrendered or copied to unauthorized persons. If you have received this communication in error, please notify the sender immediately and delete this e-mail from your system.
> 

Re: [dpdk-dev] Napatech pmd

[Michael Lilja]

> -----Original Message-----
> From: Neil Horman <nhorman@tuxdriver.com>
> Sent: 19. april 2020 23:16
> To: Michael Lilja <ml@napatech.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; Finn Christensen
> <fc@napatech.com>; dev@dpdk.org; Bent Kuhre <bk@napatech.com>;
> techboard@dpdk.org
> Subject: Re: [dpdk-dev] Napatech pmd
> 
> On Fri, Apr 17, 2020 at 04:38:42AM +0000, Michael Lilja wrote:
> > > -----Original Message-----
> > > From: Neil Horman <nhorman@tuxdriver.com>
> > > Sent: 17. april 2020 04:55
> > > To: Thomas Monjalon <thomas@monjalon.net>
> > > Cc: Finn Christensen <fc@napatech.com>; dev@dpdk.org; Bent Kuhre
> > > <bk@napatech.com>; Michael Lilja <ml@napatech.com>;
> > > techboard@dpdk.org
> > > Subject: Re: [dpdk-dev] Napatech pmd
> > >
> > > On Tue, Mar 31, 2020 at 10:07:12PM +0200, Thomas Monjalon wrote:
> > > > 31/03/2020 21:56, Neil Horman:
> > > > > On Tue, Mar 31, 2020 at 02:29:08PM +0200, Thomas Monjalon
> wrote:
> > > > > > 31/03/2020 14:17, Neil Horman:
> > > > > > > On Tue, Mar 31, 2020 at 01:25:25PM +0200, Thomas Monjalon
> > > wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Raising this topic again.
> > > > > > > >
> > > > > > > > As said in the past, it is better to have this PMD
> inside
> > > DPDK.
> > > > > > > > We discussed some concerns, but I think the consensus
> was
> > > > > > > > to integrate Napatech PMD anyway.
> > > > > > > >
> > > > > > > > I am sad that you did not feel welcome enough to follow
> up
> > > > > > > > with patches during all these years.
> > > > > > > > Please would you like to restart the upstreaming
> process?
> > > > > > > >
> > > > > > > Whats changed here?
> > > > > >
> > > > > > Nothing changed, except years.
> > > > > >
> > > > > > > I still don't see what the advantage is to accepting this
> > > > > > > code
> > > in the DPDK tree.
> > > > > > > No one will be able to use it without accepting Napatechs
> > > > > > > license for their underlying library.  As such, the code
> > > > > > > can't really be maintained at all by anyone other than
> > > > > > > Napatech in
> > > the
> > > > > > > community, and so may as well just be maintained as an out
> > > > > > > of
> > > tree driver.
> > > > > >
> > > > > > You are the only one having this concern.
> > > > > I don't think its wise to assume that silence implies
> acceptance.
> > > > >
> > > > > > Nobody from the Technical Board looks to be against the
> > > acceptance.
> > > > > >
> > > > > > The advantage is simple: Napatech customers will be able to
> > > > > > run
> > > any DPDK version.
> > > > > Why is that not possible by having napatech maintain an out-
> of-
> > > tree
> > > > > PMD?  Theres no reason that can't be done.
> > > >
> > > > They are maintaining an out-of-tree PMD:
> > > > https://github.com/napatech/dpdk/releases
> > > >
> > > > I'm just trying to improve the situation, avoiding DPDK forks.
> > > >
> > > >
> > > >
> > > Apologies, I completely missed responding to this note
> > >
> > > I took a look at the PMD above.  Its not an open source
> > > implementation of their driver, its the same thing they offered 4
> > > years ago, a skeleton pmd that still uses the same closed licensed
> library.
> > >
> > > It was my understanding that they were working on a completely
> open
> > > sourced PMD that could be generally useful to the community.  If
> > > that exists, then yes, by all means, lets take a look at it, and
> > > consider merging it.  That effort deserves consideration.
> > >
> > > This however, is the same thing we saw last time.  Theres no
> benefit
> > > in including that
> > >
> > > Neil
> > I understand the confusion. The PMD in our github is still, as you
> correctly state, based on our closed source driver and only a
> skeleton. We are working on a open source version, but currently that
> is WIP and not pushed yet. I'll let you know when there is something
> to look at.
> >
> 
> So, I have to ask.  I referenced this email from 2016 earlier in this
> thread:
> https://mails.dpdk.org/archives/dev/2016-September/046522.html
> 
> Where a colleague of yours from Napatech noted that you were working
> on an fully open source driver.  Given that you have been working on
> this to some degree since then, I would presume that you could share
> what code you have thus far.  Can you place the code you have written
> thus far in a public repository so we can start reviewing it?
> 
> Thanks
> Neil
Actually the open-source driver development has been on hold until just recently, due to other priorities. We just recently allocated a new team to do the open source driver, a team of people who has not been working with DPDK before, so the learning curve is steep for these guys. I will check up on how far they are and if they are ready to share something. 

Michael

Re: [dpdk-dev] Napatech pmd

[Thomas Monjalon]

Hi Michael,

20/04/2020 07:05, Michael Lilja:
> Actually the open-source driver development has been on hold until just recently, due to other priorities. We just recently allocated a new team to do the open source driver, a team of people who has not been working with DPDK before, so the learning curve is steep for these guys. I will check up on how far they are and if they are ready to share something.

Do you have an update for the DPDK community please?

Re: [dpdk-dev] Napatech pmd

[Michael Lilja]

Hi Thomas,

The work has not progressed as expected, so we have delays. The intention is still to provide a open source PMD, but at the moment I cannot promise any timelines.

Regards,
Michael

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: 11. december 2020 09:37
> To: Michael Lilja <ml@napatech.com>
> Cc: dev@dpdk.org; Finn Christensen <fc@napatech.com>; Bent Kuhre
> <bk@napatech.com>
> Subject: Re: [dpdk-dev] Napatech pmd
> 
> Hi Michael,
> 
> 20/04/2020 07:05, Michael Lilja:
> > Actually the open-source driver development has been on hold until
> just recently, due to other priorities. We just recently allocated a
> new team to do the open source driver, a team of people who has not
> been working with DPDK before, so the learning curve is steep for
> these guys. I will check up on how far they are and if they are
> ready to share something.
> 
> Do you have an update for the DPDK community please?
>