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 CE154A04B2; Mon, 4 May 2020 19:19:44 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A37E31D446; Mon, 4 May 2020 19:19:44 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 3EB541D16B for ; Mon, 4 May 2020 19:19:43 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 82E955C00ED; Mon, 4 May 2020 13:19:42 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 04 May 2020 13:19:42 -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=fm1; bh= ZhhZBmKzMXu3bJwJPFA2/yw82XqsLrU5gmSRuM4NWNs=; b=r01VIs1xOqQucNTo BRyhxPIeayn26yPDySTEjyEA5HdCli4KQyocLV2UWZBDvXGSwHalrsutXGDKLzWy YdWQBz22axtTxRDSoAzhIdgjP5BmG7y27ti+5AycY9xxoGeQTyC+nh+b8+/DuvQ6 XKENjDu/m1Tgysmq6gkBDftwMVbwAVgS6tti7lZj3ULwo1V52LCMSohyhXJPbP3V qPHFseVhfUtCHVH/WiYtcbrMNOgpMgEWzLg3QdtOJlmf0rmUMePlHJ7xbqpEeJnP ibAoh5ViCxKHBcmD1uIvh7oxWLePL9AcJVl8WpGWatgXhabx/9V+IlGq7eq21d0w 2s4twg== 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=ZhhZBmKzMXu3bJwJPFA2/yw82XqsLrU5gmSRuM4NW Ns=; b=E3mKWQoQ3NJ3+ys6Zh0aGwEtG1wpm4S6hMxML+h4Tw5ZPuPy8gzxCWk4J BRyfJYSV/FA3cmCZXEu1aw6I9X/gGDJmJvv7E1F6nDVAYT3xW8qDrJNFORt+XZuB FSJ35n3BSFZ3urEHkSec6+aQ+8o3lt484G2qh9kxPHTffdG6oMqnuKEEI+SPTtyM M/5LBtT1OHFhYK9/Csb28pEoTUcE2vj1XWUhNbRlCkRJtEVrZV0V83sScCYFYOIG 6jnoG/BT0DHexI0yp/Qb5Ba6GCNNLqsdMsX8fALRLrTHSNv0sD436XquJobskIK2 xhjQltxnklMJcwvj3pAjaaGJqq/hw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjeeggddutdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght 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 7628E3280064; Mon, 4 May 2020 13:19:41 -0400 (EDT) From: Thomas Monjalon To: "Chautru, Nicolas" Cc: Akhil Goyal , "dev@dpdk.org" , "Richardson, Bruce" , "Yigit, Ferruh" Date: Mon, 04 May 2020 19:19:40 +0200 Message-ID: <3297014.iIbC2pHGDl@thomas> In-Reply-To: <1183128033837D43A851F70F33ED5C578940A89F@FMSMSX109.amr.corp.intel.com> References: <1585526580-113508-1-git-send-email-nicolas.chautru@intel.com> <1183128033837D43A851F70F33ED5C57893CA2A6@ORSMSX155.amr.corp.intel.com> <1183128033837D43A851F70F33ED5C578940A89F@FMSMSX109.amr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 10/13] baseband/fpga_5gnr_fec: add configure function 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" 02/05/2020 01:15, Chautru, Nicolas: > Hi Akhil, Thomas, > > Following up on that previous discussion below so that to confirm whether there is an available option to handle this usecase within DPDK repo. > > Basically traditional deployment for VRAN relies on BBDEV/DPDK running within container where the workload is processed behind BBDEV API bounded to a VF of the accelerator, all that is fully covered currently in 20.05. > Conversely an application from baremetal still has to be run at initialization to do the required register poking to PF MMIO so that to configure the HW so that the VF is functional. Without this it is not possible to use the VF driver form within the container. Said otherwise the BBDEV VF PMD cannot be even tested with DPDK repo (only the PF PMD with the workaround discussed in the previous discussion). > That small userspace application is purely doing mmap and writing to register based on xml file input (relying on igb_uio bounded to PF, or other vanilla kernel module) and has no dependency on rest of DPDK (DPDK would not be installed outside of the container since no packet or wireless workload is actually run from there). > Is that sensible to add such a small companion application within the related PMD directory even if it has no dependency on DPDK libraries per se, only the fact that is required just to be able to use BBDEV from the VF. > On one hand I see reason not to do this as this is not a DPDK application per se, but that companion HW application is still required to be able for anyone to use BBDEV driver + being within the same repo enforces that there is no risk of version mismatch. The other option being to put that on a separate repo outside of DPDK causing fragmentation of ingredients across repos. > > I wanted to check whether you had any strong opinion on this topic and whether a patch with such a companion simple user application may be approved. I feel it is best to have the required app in the PMD directory, as in "batteries included". -------------------------- > > > BTW what is the need of a pmd API to configure the fpga? > > > Is it not possible to do that as one of rte_bbdev_ops ? > > > > This configuration is done agnostically of bbdev, the application doesn't need to > > know there is actual HW device requiring to be configured below the hood. > > Also this operation would be possible for the VF driver which doesn't have > > access to related registers. > > Typical deployment is within a container environment and this configuration is > > done without any need of any dependency on anything from librte_bbdev. > > > > Something we were considering was to push a standalone application (without > > dependency on BBDEV or even DPDK) to do that configuration from PF. > > Currently DPDK community are only able to run the PF driver, since to run from > > the VF would need a separate application to configure the device to allow > > usage from VF. > > We need to provide such application externally to DPDK currently (pretty much > > that function wrapped up with args and xml parsing). > > So we were wondering whether this could still be provided with DPDK (even if > > application has no DPDK dependency) or just push it externally on git hub. I see > > pros and cons, any view on that or similar concern for other crypto drivers?