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 1420EA0350; Fri, 26 Jun 2020 12:09:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 594F61BEA7; Fri, 26 Jun 2020 12:09:03 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id A41BE1BE88 for ; Fri, 26 Jun 2020 12:09:01 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 17FE85C00C1; Fri, 26 Jun 2020 06:09:01 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 26 Jun 2020 06:09:01 -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= sQmKtbIu+IblKy2+q+fZAI/YCD6IQLqmMLFay7a0GdA=; b=Zb6U1BeveRfUwLE3 i5TL/ClXm+pMIQKKbcOHqqLLNU6UdMnpRw2jKlgE+GrQq3KmTmgviEQKHHZH67pD v6hOggPQx8muaAF/OXaxwadKwvq9CHGfHiZ6ZQ7OWOB/PZTR6FTlXN0bFKH3xw9V /kcIqmYV8oAQPSwdwtAxnHCf60feyXVoDuf1kP0hwEJ/TadR+3mZAsx0fVl9n1jz Dz7HihZzZ7fmhgqdkq+AKpE1Yy5bppRnT9b+qGq5/TkVhRuuh6gAx++a9FZnN83t 7sLTPOD6dLP0G5p3vi5Fe4xR7Ysvdt3Y2yR3v4mgRDcqBauhCL8xVTA68ZSGgHww DsOVSw== 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=fm3; bh=sQmKtbIu+IblKy2+q+fZAI/YCD6IQLqmMLFay7a0G dA=; b=kFWozF7x7S99ZyM0lDacipoBo5c1WquEqXBqEmAlNLRqHz1vPkLGomGq7 97aXCM7oxfB39oAOiXURxVZhLi7GQQNCThs5VV9qVdM8FmtVjNJiQiQhoVxgA4xK SonhXakuST3Sq8hzBuqHlIf+MQzW8FaFvJFIVXz3ygfZJ5Kv3fh9epVanZmt+f/V U0w+D2RSSi93p+NIgDJ7CGzZgiXt9wi5yekA5YxDKX94AD0EHSrzfAnXstMhoWs9 /DT6eQIEKIrzq8jUjL20qe8NhYrcJmTZ2shjMn5j8r0gOcVu9daSz1RRGdkOUusf t68kjHO79jA43YGCA2sATAmNiq3qw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeluddgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepgeejfffhhfeghfetveffgeffteelveekhffghfefgedvleeuveet fffgudelvefhnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepjeejrddufe egrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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 D53393280067; Fri, 26 Jun 2020 06:08:59 -0400 (EDT) From: Thomas Monjalon To: "Chautru, Nicolas" Cc: Akhil Goyal , "dev@dpdk.org" , "Richardson, Bruce" , "Yigit, Ferruh" Date: Fri, 26 Jun 2020 12:08:58 +0200 Message-ID: <5002345.Tnmucr0XKv@thomas> In-Reply-To: References: <1585526580-113508-1-git-send-email-nicolas.chautru@intel.com> <2158398.uQ6CQvYSmG@thomas> 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" 26/06/2020 03:14, Chautru, Nicolas: > > From: Thomas Monjalon > > 25/06/2020 02:30, Chautru, Nicolas: > > > > From: Thomas Monjalon : > > > > 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". > > > > > > > > > > Hi Thomas, > > > For such a companion application to configure the HW within the PMD > > directory I want to confirm two things before pushing a patch : > > > - This is okay with you for it to build outside of the DPDK build flow. > > Ie. Separate Makefile, not planning meson support. Again zero DPDK libraries > > dependency. > > > > I think it should be built as part of the PMD. > > Why not? > > For the same reason as above : you would not deploy this companion application in the same OS or container/VM as DPDK; they would be built without dependency on each other, but still provided together so that you can actually have all the ingredients in one place without mismatch and be able to actually use the PMD will all required ingredients in one place. OK I missed the DPDK environment is not the same as the environment of the companion application. > Also based on the dependency below, even if adding option to build within same DPDK meson framework, it would not build by default by anyone as the dependency repo would be lacking. What is the dependency? I assume it is freely and easily downloadable. > For that reason that would be a bit artificial to me to be built with the PMD really, but I could be convinced otherwise. > Any thought Thomas? OK If you think the application is tightly related to the PMD, I think it could be hosted with it. > > > - This is okay with you for it to have dependency on other open- > > source library to build it. Ie. we are currently linking to this > > https://github.com/benhoyt/inih (BSD license) as a simple input config file > > parsing. > > > > No problem with dependencies.