Re: [dpdk-dev] [PATCH v2 10/13] baseband/fpga_5gnr_fec: add configure function

["Chautru, Nicolas" <nicolas.chautru@intel.com>]

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

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