DPDK patches and discussions
 help / color / mirror / Atom feed
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>
Subject: Re: [dpdk-dev] [PATCH v2 10/13] baseband/fpga_5gnr_fec: add configure function
Date: Fri, 1 May 2020 23:15:51 +0000	[thread overview]
Message-ID: <1183128033837D43A851F70F33ED5C578940A89F@FMSMSX109.amr.corp.intel.com> (raw)
In-Reply-To: <1183128033837D43A851F70F33ED5C57893CA2A6@ORSMSX155.amr.corp.intel.com>

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. 

Thanks and regards, 
Nic

 
> > 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?
> 
> >

  reply	other threads:[~2020-05-01 23:16 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-30  0:02 [dpdk-dev] [PATCH v2 00/13] drivers/baseband: add PMD for FPGA 5GNR FEC Nicolas Chautru
2020-03-30  0:02 ` [dpdk-dev] [PATCH v2 01/13] bbdev: add capability flag for filler bits inclusion in HARQ Nicolas Chautru
2020-03-30  0:02 ` [dpdk-dev] [PATCH v2 02/13] bbdev: expose device HARQ buffer size at device level Nicolas Chautru
2020-03-30  0:02 ` [dpdk-dev] [PATCH v2 03/13] drivers/baseband: add PMD for FPGA 5GNR FEC Nicolas Chautru
2020-03-30  0:02 ` [dpdk-dev] [PATCH v2 04/13] baseband/fpga_5gnr_fec: add register definition file Nicolas Chautru
2020-03-30  0:02 ` [dpdk-dev] [PATCH v2 05/13] baseband/fpga_5gnr_fec: add device info_get function Nicolas Chautru
2020-04-16 18:15   ` Akhil Goyal
2020-04-16 21:20     ` Chautru, Nicolas
2020-03-30  0:02 ` [dpdk-dev] [PATCH v2 06/13] baseband/fpga_5gnr_fec: add queue configuration Nicolas Chautru
2020-04-11  3:13   ` Xu, Rosen
2020-04-14  0:16     ` Chautru, Nicolas
2020-04-15  6:13       ` Xu, Rosen
2020-04-15 15:51         ` Chautru, Nicolas
2020-04-16  1:09           ` Xu, Rosen
2020-03-30  0:02 ` [dpdk-dev] [PATCH v2 07/13] baseband/fpga_5gnr_fec: add LDPC processing functions Nicolas Chautru
2020-03-30  0:02 ` [dpdk-dev] [PATCH v2 08/13] baseband/fpga_5gnr_fec: add HW error capture Nicolas Chautru
2020-03-30  0:02 ` [dpdk-dev] [PATCH v2 09/13] baseband/fpga_5gnr_fec: add debug functionality Nicolas Chautru
2020-03-30  0:02 ` [dpdk-dev] [PATCH v2 10/13] baseband/fpga_5gnr_fec: add configure function Nicolas Chautru
2020-04-15 15:40   ` Power, Niall
2020-04-16 19:30   ` Akhil Goyal
2020-04-16 21:45     ` Chautru, Nicolas
2020-05-01 23:15       ` Chautru, Nicolas [this message]
2020-05-04 17:19         ` Thomas Monjalon
2020-06-25  0:30           ` Chautru, Nicolas
2020-06-25  8:13             ` Thomas Monjalon
2020-06-26  1:14               ` Chautru, Nicolas
2020-06-26 10:08                 ` Thomas Monjalon
2020-07-10 22:48                   ` Chautru, Nicolas
2020-03-30  0:02 ` [dpdk-dev] [PATCH v2 11/13] baseband/fpga_5gnr_fec: add harq loopback capability Nicolas Chautru
2020-03-30  0:02 ` [dpdk-dev] [PATCH v2 12/13] baseband/fpga_5gnr_fec: add interrupt support Nicolas Chautru
2020-04-16 18:43   ` Akhil Goyal
2020-03-30  0:03 ` [dpdk-dev] [PATCH v2 13/13] doc: add feature matrix table for bbdev devices Nicolas Chautru
2020-04-15 15:40 ` [dpdk-dev] [PATCH v2 00/13] drivers/baseband: add PMD for FPGA 5GNR FEC Power, Niall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1183128033837D43A851F70F33ED5C578940A89F@FMSMSX109.amr.corp.intel.com \
    --to=nicolas.chautru@intel.com \
    --cc=akhil.goyal@nxp.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).