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 495CFA0562; Tue, 31 Mar 2020 14:39:29 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 23B672C15; Tue, 31 Mar 2020 14:39:28 +0200 (CEST) Received: from mail02.napatech.com (mail02.napatech.com [188.120.77.119]) by dpdk.org (Postfix) with ESMTP id 151E4F12; Tue, 31 Mar 2020 14:39:27 +0200 (CEST) Received: from mail02.napatech.com (localhost [127.0.0.1]) by mail02.napatech.com (Postfix) with ESMTP id 850669CC4E; Tue, 31 Mar 2020 14:39:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=napatech.com; s=mar2017; t=1585658366; bh=XJyujxDLhwRhQE2EKwbvAqrygJJwPO5JBNZF2ox0d2o=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=ZFyALDIZyIWy7pIlfmzJvysSxW7xanqm6Kt0c9AyEJ78BQ0qIFnLYGh0mayOErFi4 AdtI1LGMf1e2QGS5FZ6JPNGeVHvSk9aPV78IZKRBonVCheKtJe3z24ltBdxFw5OfoH nS6uOu0k1UOj96YTy38U6N7USfbebKNh0KSGiSgVq9rB4v++3wGvCDPvVex8mk92z6 LJyHgoPUSJL5M6cUP4uSd9x2yfgdDypHxNY9P9lN8QWAiQJYFkPB2yAakt34oqlekw bMncKDjxj8l1OzWQ737QakhLsNC3heiEgJLiyFoiTI+1xu0/J9aRvSDxpYOie2njnt LtECP47O2FCzA== Received: from localhost (localhost [127.0.0.1]) by mail02.napatech.com (Postfix) with ESMTP id 81B299CC4D; Tue, 31 Mar 2020 14:39:26 +0200 (CEST) X-Virus-Scanned: by SpamTitan at napatech.com Received: from mail02.napatech.com (localhost [127.0.0.1]) by mail02.napatech.com (Postfix) with ESMTP id 22B259CCC6; Tue, 31 Mar 2020 14:39:24 +0200 (CEST) Authentication-Results: mail02.napatech.com; none Received: from mail.napatech.com (cph-gen-exch02.napatech.com [10.240.1.84]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail02.napatech.com (Postfix) with ESMTPS id 8EA359CCC0; Tue, 31 Mar 2020 14:39:21 +0200 (CEST) Received: from cph-gen-exch02.napatech.com (10.240.1.84) by cph-gen-exch02.napatech.com (10.240.1.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 31 Mar 2020 14:39:17 +0200 Received: from cph-gen-exch02.napatech.com ([fe80::581:51a1:ac3f:84e]) by cph-gen-exch02.napatech.com ([fe80::581:51a1:ac3f:84e%12]) with mapi id 15.01.1913.005; Tue, 31 Mar 2020 14:39:17 +0200 From: Michael Lilja To: Thomas Monjalon , Neil Horman CC: Finn Christensen , "dev@dpdk.org" , "Bent Kuhre" , "techboard@dpdk.org" Thread-Topic: [dpdk-dev] Napatech pmd Thread-Index: AQHWB1gAjoqbSs4S00yV0CaMaRpMEahiobgg Date: Tue, 31 Mar 2020 12:39:17 +0000 Message-ID: References: <3917216.uADA5c2rLh@xps> <20200331121721.GA3858830@hmswarspite.think-freely.org> <11835288.hYdu0Ggh8K@xps> In-Reply-To: <11835288.hYdu0Ggh8K@xps> Accept-Language: en-US, da-DK, de-DE, de-CH, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.240.51.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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" 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 dri= ver 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 > -----Original Message----- > From: Thomas Monjalon > Sent: 31. marts 2020 14:29 > To: Neil Horman > Cc: Finn Christensen ; dev@dpdk.org; Bent Kuhre > ; Michael Lilja ; techboard@dpdk.org > Subject: Re: [dpdk-dev] Napatech pmd >=20 > 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? >=20 > Nothing changed, except years. >=20 > > 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. >=20 > You are the only one having this concern. > Nobody from the Technical Board looks to be against the acceptance. >=20 > The advantage is simple: Napatech customers will be able to run any > DPDK version. >=20 >=20 > > > 08/01/2018 14:08, Finn Christensen: > > > > Hi Thomas, > > > > > > > > Thanks for bringing this discussion up again. > > > > > > > > The Napatech PMD is build on top of our proprietary driver. The > reason is basically that we utilize many years of driver development > and thus reuses the FPGA controlling code in the DPDK PMD. The > Napatech driver suite is still closed source. > > > > The current NTNIC PMD dynamically links a Napatech proprietary > NTAPI library to control the FPGA on our NICs. > > > > > > > > We did think of the PMD as being our responsibility to keep > updated towards the Napatech NIC communication, and that we would be > engaged and asked to modify accordingly if changes in DPDK required > that (maintainer). Furthermore, the PMD compiles with no issues, when > NTNIC is enabled. > > > > We have plans to write a stand-alone PMD, but this is not a > small task to do, therefore we haven't got to that yet. > > > > > > > > If the DPDK community would accept the dynamic linking to a > proprietary library, from inside our PMD, then it would be great. > > > > > > > > Let me know what you think. Or maybe you have ideas to what else > we could do to make it upstream. > > > > > > > > Thanks, > > > > Finn > > > > > > > > > > > > >-----Original Message----- > > > > >From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > >Sent: 5. januar 2018 16:34 > > > > >To: Finn Christensen > > > > >Subject: Re: [dpdk-dev] standardize device identification > > > > > > > > > >It leads to a totally different question: > > > > >Can we discuss again how to integrate your driver in DPDK > upstream? > > > > >Please explain again your situation in a new thread. > > > > > > > > > > > > > > > > > > > > > > > > >=20 >=20 >=20 >=20