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 D2D76A057B; Wed, 1 Apr 2020 14:40:42 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3BD0C1BE0C; Wed, 1 Apr 2020 14:40:42 +0200 (CEST) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 052DD1BDAC; Wed, 1 Apr 2020 14:40:41 +0200 (CEST) Received: from 2606-a000-111b-43ee-0000-0000-0000-1bf2.inf6.spectrum.com ([2606:a000:111b:43ee::1bf2] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1jJcfS-0004rJ-VC; Wed, 01 Apr 2020 08:40:33 -0400 Date: Wed, 1 Apr 2020 08:40:22 -0400 From: Neil Horman To: Thomas Monjalon Cc: Stephen Hemminger , Michael Lilja , Finn Christensen , "dev@dpdk.org" , Bent Kuhre , "techboard@dpdk.org" Message-ID: <20200401124022.GA3959020@hmswarspite.think-freely.org> References: <20200331075845.28c3d4e3@hermes.lan> <20200331195137.GB3858830@hmswarspite.think-freely.org> <21144485.BlLV05Wm1B@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21144485.BlLV05Wm1B@xps> 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 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 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