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.
