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 B4822A0562; Tue, 31 Mar 2020 13:25:29 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8CE6A322C; Tue, 31 Mar 2020 13:25:29 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 63EAF2C6D for ; Tue, 31 Mar 2020 13:25:28 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B8A855C02F9; Tue, 31 Mar 2020 07:25:27 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 31 Mar 2020 07:25:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=mvBOmaKb7gyjsTbwhmKj8lzZXGX74aVjZvch7sJx/6g=; b=bk8WfyXE5MKl uxlA45cs2MK3ROSrgKquPCWx7DObctXsY9HexaXk0dEpTIyNDFcanfKzm8fYQnRV sVF5+gVTKakftazn6+WS59PzwYUTD5qVMlUi8vDpqRDvuRwR5msrR8mWjU5oJvKW wQlT0z1nwGCV+Bbz0KeEsYj7/vddjHg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=mvBOmaKb7gyjsTbwhmKj8lzZXGX74aVjZvch7sJx/ 6g=; b=JiYQPjaGY0HbrBywNbYzP3M3H4zCHTdlc5sREg25dGtYX0HSLSB8h4h74 vtDjLLQWyLuctmhbmr3PFty5wTgStvRJ4pL686ZnrhY2KqchZK+YP9fQoEfLnq0K +5HnE/RSg1VV63ArWN1oWcFkTte/fljO1LgTw6mZapAJFLPUeI9Nb+x4G7G04u8S uuRYDJrSXU0KkIdyTpU7DkEMhvp2xy28fjsx9E/72vmmKE6PAvGZ8gkl1Lr8Ee3G I6s5pMZIF84g2Ikm4o6zVwp3ERqhzW2YtUESn1Z4+hU9W7kZ2nmMmedyKl51bI0I G2xzIqE5gvGs0VqUatKmLsbvVuKsQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtddtgddtiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 7F9DB3280060; Tue, 31 Mar 2020 07:25:26 -0400 (EDT) From: Thomas Monjalon To: Finn Christensen Cc: dev@dpdk.org, Bent Kuhre , Michael Lilja Date: Tue, 31 Mar 2020 13:25:25 +0200 Message-ID: <3917216.uADA5c2rLh@xps> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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, 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? 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. >