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 4B917A0562; Tue, 31 Mar 2020 21:51:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DD09D1C1F1; Tue, 31 Mar 2020 21:51:55 +0200 (CEST) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 9C8A61C12D; Tue, 31 Mar 2020 21:51:54 +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 1jJMvC-0005Kl-Qq; Tue, 31 Mar 2020 15:51:45 -0400 Date: Tue, 31 Mar 2020 15:51:37 -0400 From: Neil Horman To: Stephen Hemminger Cc: Michael Lilja , Thomas Monjalon , Finn Christensen , "dev@dpdk.org" , Bent Kuhre , "techboard@dpdk.org" Message-ID: <20200331195137.GB3858830@hmswarspite.think-freely.org> References: <3917216.uADA5c2rLh@xps> <20200331121721.GA3858830@hmswarspite.think-freely.org> <11835288.hYdu0Ggh8K@xps> <20200331075845.28c3d4e3@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200331075845.28c3d4e3@hermes.lan> 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 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.