[dpdk-dev] Napatech pmd

Thomas Monjalon thomas at monjalon.net
Tue Mar 31 22:07:12 CEST 2020


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.




More information about the dev mailing list