From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 93D6AA0588; Fri, 17 Apr 2020 04:55:18 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 726651DE06; Fri, 17 Apr 2020 04:55:17 +0200 (CEST) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id BB8521DDEE; Fri, 17 Apr 2020 04:55:15 +0200 (CEST) Received: from [107.15.85.130] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1jPH9j-00067m-C4; Thu, 16 Apr 2020 22:55:09 -0400 Date: Thu, 16 Apr 2020 22:54:57 -0400 From: Neil Horman To: Thomas Monjalon Cc: Finn Christensen , dev@dpdk.org, Bent Kuhre , Michael Lilja , techboard@dpdk.org Message-ID: <20200417025457.h4uqif7qtjfb2x2q@penguin.lxd> References: <11835288.hYdu0Ggh8K@xps> <20200331195655.GC3858830@hmswarspite.think-freely.org> <4836428.jY9Djz4Zq0@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4836428.jY9Djz4Zq0@xps> User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] Napatech pmd X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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