From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f46.google.com (mail-pg0-f46.google.com [74.125.83.46]) by dpdk.org (Postfix) with ESMTP id 1E5F71B16F for ; Mon, 8 Jan 2018 16:32:00 +0100 (CET) Received: by mail-pg0-f46.google.com with SMTP id r2so5735860pgq.13 for ; Mon, 08 Jan 2018 07:31:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=+dDM0Zy6FwIVWmSyVscAW6ZBv2wK5PKIbtWWNHB3iHY=; b=usCMEViK1gGn7pCBIiBxlZk7waZZvzlfvw5ZwOjIdZabPe+BIgmZVCQozjccpJbte8 4aMXESjcsCHmiBIHspPd5rqEfygvssnTcjiKSMmwoVUxEPn82Sq/rlijdkeyR1PHXYYF Otp+NVV640GX6vLBtHI3BLpDW2mxTvF/8JfDUvQZhaGTv8AzJimiPfVNgElctXKHe1DH Na+sp2DT6eDMuij0VlixVoy5u2+4MzCxtG83RJeQECBGhbDwuMJz1s0qPTICDH18SAa+ i6f9k1eKrKW/V4UI5rV1Avz1lWMt4pagMvLDU6ynAhA30AoLKMAT2Q8T4jhMgSHHAgXj 3vqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=+dDM0Zy6FwIVWmSyVscAW6ZBv2wK5PKIbtWWNHB3iHY=; b=ibKaQAOJ6n9RhJ04v6DRmuON0x+SiUhjHh/aiy4sk+YJQIcbNiQeiRwvHyTvYVoYFJ lY9UL6ABo6iUpmGzixnZ6wmpegaHm+KOquExySVXi4Np6G7HtzbRkOKyw0p38BC/RkIp jhX8MwXELt/EkBLr3qu+b8FG+cbtIlgpaTdxIhjhyaBS4VIGTG/LpWQ+hpuEO0x0AZE9 2qEyEzdPrNXIL+F9F6Km5rH9A93d9RLh5KAfD3Ll/FkZf+ZegwDYS57oJ8F210BE1tSa LmLv9eVeLrDwx3K8ROClzdY7i6bN/7LthyFFq7u/QOrVL/329IvmlPb/LAloRDD1cMZB VTFQ== X-Gm-Message-State: AKGB3mJ5ewy+13O0WQIzq35xMsx/3fzihwKboEK1Fxn7ifomg+pZvs0h 3WTsNG2BebDhi2HyyY/+Dv2gw07Q6/8= X-Google-Smtp-Source: ACJfBosWV3lyrGrIkHQau1pO8KLlafY0eUWLmXTnADoYZuOGIIMaprv/6E9ouU2UGW/B5K9hEgAVPw== X-Received: by 10.159.244.147 with SMTP id y19mr4225337plr.4.1515425519202; Mon, 08 Jan 2018 07:31:59 -0800 (PST) Received: from xeon-e3 (204-195-18-133.wavecable.com. [204.195.18.133]) by smtp.gmail.com with ESMTPSA id e18sm27565205pfb.168.2018.01.08.07.31.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 Jan 2018 07:31:59 -0800 (PST) Date: Mon, 8 Jan 2018 07:31:55 -0800 From: Stephen Hemminger To: Thomas Monjalon Cc: Finn Christensen , dev@dpdk.org Message-ID: <20180108073155.09e17a9f@xeon-e3> In-Reply-To: <1643500.LyBOxPcb61@xps> References: <1643500.LyBOxPcb61@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Mon, 08 Jan 2018 15:32:00 -0000 On Mon, 08 Jan 2018 16:15:47 +0100 Thomas Monjalon wrote: > Hi, > > 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. > > This standalone PMD would be open and BSD licensed? > > > If the DPDK community would accept the dynamic linking to a proprietary library, from inside our PMD, then it would be great. > > Dynamic linking is OK. > I think we can accept such PMD at the condition that we can build it, > meaning we can easily download the build dependencies for free. > > > Let me know what you think. Or maybe you have ideas to what else we could do to make it upstream. > > My thinking is to allow every hardware to have a good DPDK support. > Every step in this direction is a progress. Also the API to the proprietary code must be separate from DPDK headers. Ideally the ABI for DPDK could evolve and the vendor code would not need to be updated.