From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B640FA04B2; Sat, 2 May 2020 01:16:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 085F51D99E; Sat, 2 May 2020 01:16:15 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 58C461D97C for <dev@dpdk.org>; Sat, 2 May 2020 01:16:13 +0200 (CEST) IronPort-SDR: 7TF2yGvUVHz7AZjfrS4kF6VZ+UTD5pCaoNwBpf+AXOyzzA9LGJ8aMBx1SpHIxpNJI1ogBhagVT aPeill5+Wv+A== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 May 2020 16:16:12 -0700 IronPort-SDR: 92d3BSmxzSiK+P01YRWyeRpGs2Ab0vzWuEMpumM7GgaxhoRlR6zphV65DHU1/tkl20PlRpysFB RSML5N72GVaw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,341,1583222400"; d="scan'208";a="405879150" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga004.jf.intel.com with ESMTP; 01 May 2020 16:16:11 -0700 Received: from fmsmsx113.amr.corp.intel.com (10.18.116.7) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 1 May 2020 16:15:52 -0700 Received: from FMSMSX109.amr.corp.intel.com ([169.254.15.84]) by FMSMSX113.amr.corp.intel.com ([169.254.13.51]) with mapi id 14.03.0439.000; Fri, 1 May 2020 16:15:52 -0700 From: "Chautru, Nicolas" <nicolas.chautru@intel.com> To: Akhil Goyal <akhil.goyal@nxp.com>, Thomas Monjalon <thomas@monjalon.net>, "dev@dpdk.org" <dev@dpdk.org> CC: "Richardson, Bruce" <bruce.richardson@intel.com>, "Yigit, Ferruh" <ferruh.yigit@intel.com> Thread-Topic: [PATCH v2 10/13] baseband/fpga_5gnr_fec: add configure function Thread-Index: AQHWBia5R0/Gp5PdrkGqhlhqLpHPAqh8s+sA//+q7ECAF60+UA== Date: Fri, 1 May 2020 23:15:51 +0000 Message-ID: <1183128033837D43A851F70F33ED5C578940A89F@FMSMSX109.amr.corp.intel.com> References: <1585526580-113508-1-git-send-email-nicolas.chautru@intel.com> <1585526580-113508-11-git-send-email-nicolas.chautru@intel.com> <VI1PR04MB316813AC9BB47C1E29DF543DE6D80@VI1PR04MB3168.eurprd04.prod.outlook.com> <1183128033837D43A851F70F33ED5C57893CA2A6@ORSMSX155.amr.corp.intel.com> In-Reply-To: <1183128033837D43A851F70F33ED5C57893CA2A6@ORSMSX155.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.1.200.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> Hi Akhil, Thomas,=20 Following up on that previous discussion below so that to confirm whether t= here is an available option to handle this usecase within DPDK repo.=20 Basically traditional deployment for VRAN relies on BBDEV/DPDK running with= in 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 initializat= ion 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 canno= t be even tested with DPDK repo (only the PF PMD with the workaround discus= sed in the previous discussion). That small userspace application is purely doing mmap and writing to regist= er based on xml file input (relying on igb_uio bounded to PF, or other vani= lla 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).=20 Is that sensible to add such a small companion application within the relat= ed PMD directory even if it has no dependency on DPDK libraries per se, onl= y 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 p= er se, but that companion HW application is still required to be able for a= nyone 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 se= parate repo outside of DPDK causing fragmentation of ingredients across rep= os.=20 I wanted to check whether you had any strong opinion on this topic and whet= her a patch with such a companion simple user application may be approved.= =20 Thanks and regards,=20 Nic =20 > > 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 ? >=20 > 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 hav= e > access to related registers. > Typical deployment is within a container environment and this configurati= on is > done without any need of any dependency on anything from librte_bbdev. >=20 > Something we were considering was to push a standalone application (witho= ut > 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 drive= rs? >=20 > >