[dpdk-dev] Napatech pmd

[Michael Lilja]

> -----Original Message-----
> From: Neil Horman <nhorman at tuxdriver.com>
> Sent: 17. april 2020 04:55
> To: Thomas Monjalon <thomas at monjalon.net>
> Cc: Finn Christensen <fc at napatech.com>; dev at dpdk.org; Bent Kuhre
> <bk at napatech.com>; Michael Lilja <ml at napatech.com>; techboard at 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