DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Chautru, Nicolas" <nicolas.chautru@intel.com>
Cc: Akhil Goyal <akhil.goyal@nxp.com>, "dev@dpdk.org" <dev@dpdk.org>,
	"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, 26 Jun 2020 12:08:58 +0200	[thread overview]
Message-ID: <5002345.Tnmucr0XKv@thomas> (raw)
In-Reply-To: <BY5PR11MB4451DF6740C77C0F64D1F622F8930@BY5PR11MB4451.namprd11.prod.outlook.com>

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.




  reply	other threads:[~2020-06-26 10:09 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
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 [this message]
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=5002345.Tnmucr0XKv@thomas \
    --to=thomas@monjalon.net \
    --cc=akhil.goyal@nxp.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=nicolas.chautru@intel.com \
    /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).